--- Allen <[EMAIL PROTECTED]> wrote: > Also you should keep in mind, there could simply be some really > goofy > controller option enabled, that forces the RAID5 to behave in a > "degraded" > state for reads -- forcing it to read up all the other disks in > the stripe > and calculate the XOR again, to make sure the data it read off > the disk > matches the checksum. It's rare, but I've seen it before, and > it will > cause exactly this sort of RAID5 performance inversion. Since > the XOR is > recalculated on every write and requires only reading up one > sector on a > different disk, options that do the above will result in read > scores > drastically lower than writes to the same array. > Isn't that compensated by the cache? I mean: We would just 1. read all the blocks, that correspond to the block, that is requested, 2. put them all into the cache 3. check the parity bits (XOR should be very fast; especially in comparison to the disc read times) 4. keep them in the cache (some kind of read ahead...) 5. send the requested block to the driver
-Arne __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "[EMAIL PROTECTED]"
