In response to Mark Mielke <mark@xxxxxxxxxxxxxx>: > Bill Moran wrote: > > In order to recalculate the parity, it has to have data from all disks. Thus, > > if you have 4 disks, it has to read 2 (the unknown data blocks included in > > the parity calculation) then write 2 (the new data block and the new > > parity data) Caching can help some, but if your data ends up being any > > size at all, the cache misses become more frequent than the hits. Even > > when caching helps, you max speed is still only the speed of a single > > disk. > > > If you have 4 disks, it can do either: > > 1) Read the old block, read the parity block, XOR the old block with > the parity block and the new block resulting in the new parity block, > write both the new parity block and the new block. > 2) Read the two unknown blocks, XOR with the new block resulting in > the new parity block, write both the new parity block and the new block. > > You are emphasizing 2 - but the scenario is also overly simplistic. > Imagine you had 10 drives on RAID 5. Would it make more sense to read 8 > blocks and then write two (option 2, and the one you describe), or read > two blocks and then write two (option 1). Obviously, if option 1 or > option 2 can be satisfied from cache, it is better to not read at all. Good point that I wasn't aware of. > I note that you also disagree with Dave, in that you are not claiming it > performs consistency checks on read. No system does this as performance > would go to the crapper. I call straw man :) I don't disagree. I simply don't know. There's no reason why it _couldn't_ do consistency checking as it ran ... of course, performance would suck. Generally what you expect out of RAID 5|6 is that it can rebuild a drive in the event of a failure, so I doubt if anyone does consistency checking by default, and I wouldn't be surprised if a lot of systems don't have the option to do it at all. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ wmoran@xxxxxxxxxxxxxxxxxxxxxxx Phone: 412-422-3463x4023 ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org
