Re: Very low disk performance on 5.x

>This is totally bogus to me - [...] If the disk has bad sectors or other hardware issues, this is not an atypical result. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute t

Re: Very low disk performance on 5.x

f you are using RAID5 and your requests are not aligned and sized after the RAID5 you should *expect* read performance to be poor. If you your request ends up accessing two different blocks even just once per stripe, this totally kills performance. -- Poul-Henning Kamp | UNIX since Zilog Z

Re: Very low disk performance on 5.x

In message <[EMAIL PROTECTED]>, Eric Anderson writes: >Poul-Henning Kamp wrote: >> In message <[EMAIL PROTECTED]>, Eric Anderson writes: >> >> >>>Don't mean to be terse here, but I'm talking about the same test done an >>>two diffe

Re: Very low disk performance on 5.x

In message <[EMAIL PROTECTED]>, Petri Helenius writes: >> >My tests were using RAID10 and just striping. (RAID0 might be the right >name for it) Same thing applies, and it depends on how the reqeust alignment/size and stripe alignment/size interacts. -- Poul-Henning Kamp

Re: Very low disk performance on 5.x

it right. Fixing them to do so may be more trouble than writing a better too bottom up. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be

Re: Very low disk performance on 5.x

happens in the RAID5 unit. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.

Re: Very low disk performance on 5.x

In message <[EMAIL PROTECTED]>, Allen writes: I just want to add: This is why I really would love for us to have a real RAID3 implemetation. RAID3 is not commercially viable because windows cannot use non-512 byte sectors. We can. RAID3 would scream for us. -- Poul-Hennin

Re: Very low disk performance on 5.x

8 byte sector sizes and similar madness in order to support 512 bytes sectors on the RAID3 volume. Some of them use 512 byte sector disks and internal sectorsizes of N*512 bytes and use their battery-backed cache to pretend to have 512 bytes logical sectorsize. -- Poul-Henning Kamp | UNIX sinc

Re: Very low disk performance on 5.x

you remember to disable all the debugging in FreeBSD 6-Current ? (see top of src/UPDATING) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice wha

Re: Very low disk performance on 5.x

. Just checking: what exactly did you disable ? >N.B. Current had at least on out of order lock issue while I was using >it but not while the tests where going on. Yes, current is current :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROT

Re: Very low disk performance on 5.x

; madness in order to support 512 bytes sectors on the RAID3 volume. > >I would really love the 512 + 8 byte checksum stuff that mainframes >and netapps do. Does GEOM simplify implementing something like this ? Yes, GEOM works with arbitrary sectorsizes, but far from all current GEOM classes

Re: Very low disk performance on 5.x

o doubt that this is the way we are headed, hopefully sometime in the 7-CURRENT period. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be expla

Re: Very low disk performance on 5.x

too, but it seems only fair to put the overhead in front of those three since they are already slow operations. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to mali

Re: dd(1) performance when copiing a disk to another (fwd)

ipe size of 63 sectors, a (too) large fraction of the requests will have one sector in one raid-stripe and the rest in another, which they often fail to fill by exactly one sector. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD c

Re: FreeBSD Compiler Benchmark: gcc-base vs. gcc-ports vs. clang

: run test A run test B run test C ... Throw first result away for all tests Run remaining results through ministat(1) This was a public service announcement. Poul-Henning PS: Recommended reading: http://www.larrygon

Re: FreeBSD Compiler Benchmark: gcc-base vs. gcc-ports vs. clang

t, you numbers are meaningless, because we have no idea what the signal/noise ratio is. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explain

Re: FreeBSD Compiler Benchmark: gcc-base vs. gcc-ports vs. clang

approach is better :) Much, much better. As I said, this was not to go after you personally, but to point out that we need to be more rigorous with benchmarks in general. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer