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

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 [EMAIL PROTECTED]
> 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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to