Re: Software RAID 5 and crashes

[Neil Brown]

On Sunday August 1, xuan--2004.08.01--linux-kernel--vger.kernel.org@xxxxxxxxxxx wrote:
> 
> Unfortunately, it still does not make me satisfied, because: The 
> asymmetry of "all data blocks are correct, all parity blocks are 
> suspect" should be exploited.
> Consider 4 disks joined as RAID 5. There are 4 stripes (s0, s1, s2, s3), 
> where s3 is the parity stripe.
> 
>     * <>Example 0: s3,s2,s1 are written to disk, while s0 is not written
>       to disk for some reason. The system crashes. What happens at
>       reconstruction? s3 gets replaced by s0 XOR s1 XOR s2. s0 contains
>       old (read: wrong) data.

Define "wrong"....

Supposing it had actually crashed a couple of milliseconds earlier,
when none of the blocks had been written.  Is that any more wrong? or
less? 

When ever a machine crashes, it is wrong.  Whenever a machine crashes
you lose data.   A little more or a little bit less data being "lost"
in neither here nor there.  The only thing that it really makes sense
to worry about is consistency.  RAID5 provides all the consistency it
can, and leaves the rest up to higher layers.


>     * Example 1: s0,s1,s2 are written to disk, while s3 is not written
>       to disk for some reason. The system crashes. What happens at
>       reconstruction? s3 gets replaced by s0 XOR s1 XOR s2. s0 does not
>       contain old data. The stripe which contains the old data (s3) is
>       replaced anyway during reconstruction.
> 
> If we now consider, that for each disk (as member of a RAID 5), there 
> are parity stripes and there are data stripes. Doesn't it make sense to 
> prefer data blocks over partiy blocks when writing, just to get more 
> cases of "example 1" against "example 0" than without this
> preference?

No, and definitely not at the cost of delaying any writes or
complicating the code at all.

NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/