> -----Original Message----- > From: linux-raid-owner@xxxxxxxxxxxxxxx [mailto:linux-raid- > owner@xxxxxxxxxxxxxxx] On Behalf Of Mike Hardy > Sent: Friday, November 18, 2005 2:24 PM > To: Dan Stromberg > Cc: Jure Pečar; linux-raid@xxxxxxxxxxxxxxx > Subject: Re: raid5 write performance > > > Moreover, and I'm sure Neil will chime in here, isn't the clean/unclean > thing designed to prevent this exact scenario? > > The array is marked unclean immediately prior to write, then the write > and parity write happens, then the array is marked clean. > > If you crash during the write but before parity is correct, the array is > unclean and you resync (quickly now thanks to intent logging if you have > that on) > > The non-parity blocks that were partially written are then the > responsibility of your journalling filesystem, which should make sure > there is no corruption, silent or otherwise. > > If I'm misunderstanding that, I'd love to be corrected. I was under the > impression that the "silent corruption" issue was mythical at this point > and if it's not I'd like to know. > > -Mike It is not just a parity issue. If you have a 4 disk RAID 5, you can't be sure which if any have written the stripe. Maybe the parity was updated, but nothing else. Maybe the parity and 2 data disks, leaving 1 data disk with old data. Beyond that, md does write caching. I don't think the file system can tell when a write is truly complete. I don't recall ever having a Linux system crash, so I am not worried. But power failures cause the same risk, or maybe more. I have seen power failures, even with a UPS! Guy > > Dan Stromberg wrote: > > Would it really be that much slower to have a journal of RAID 5 writes? > > > > On Fri, 2005-11-18 at 15:05 +0100, Jure Pečar wrote: > > > >>Hi all, > >> > >>Currently zfs is a major news in the storage area. It is very > interesting to read various details about it on varios blogs of Sun > employees. Among the more interesting I found was this: > >> > >>http://blogs.sun.com/roller/page/bonwick?entry=raid_z > >> > >>The point the guy makes is that it is impossible to atomically both > write data and update parity, which leaves a window of crash that would > silently leave on-disk data+paritiy in an inconsistent state. Then he > mentions that there are software only workarounds for that but that they > are very very slow. > >> > >>It's interesting that my expirience with veritas raid5 for example is > just that: slow to the point of being unuseable. Now, I'm wondering what > kind of magic does linux md raid5 does, since its write performance is > quite good? Or, does it actually do something regarding this? :) > >> > >>Niel? > >> > > > > > > - > > To unsubscribe from this list: send the line "unsubscribe linux-raid" in > > the body of a message to majordomo@xxxxxxxxxxxxxxx > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > - > To unsubscribe from this list: send the line "unsubscribe linux-raid" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
