Hi,
On Wed, 12 Jan 2000 00:12:55 +0200 (IST), Gadi Oxman
<[EMAIL PROTECTED]> said:
> Stephen, I'm afraid that there are some misconceptions about the
> RAID-5 code.
I don't think so --- I've been through this with Ingo --- but I
appreciate your feedback since I'm getting inconsistent advise here!
Please let me explain...
> In an early pre-release version of the RAID code (more than two years
> ago?), which didn't protect against that race, we indeed saw locked
> buffers changing under us from the point in which we computed the
> parity till the point in which they were actually written to the disk,
> leading to a corrupted parity.
That is not the race. The race has nothing at all to do with buffers
changing while they are being used for parity: that's a different
problem, long ago fixed by copying the buffers.
The race I'm concerned about could occur when the raid driver wants to
compute parity for a stripe and finds some of the blocks are present,
and clean, in the buffer cache. Raid assumes that those buffers
represent what is on disk, naturally enough. So, it uses them to
calculate parity without rereading all of the disk blocks in the stripe.
The trouble is that the standard practice in the kernel, when modifying
a buffer, is to make the change and _then_ mark the buffer dirty. If
you hit that window, then the raid driver will find a buffer which
doesn't match what is on disk, and will compute parity from that buffer
rather than from the on-disk contents.
> 1. n dirty blocks are scheduled for a stripe write.
That's not the race. The problem occurs when only one single dirty
block is scheduled for a write, and we need to find the contents of the
rest of the stripe to compute parity.
> Point (2) is also incorrect; we have taken care *not* to peek into
> the buffer cache to find clean buffers and use them for parity
> calculations. We make no such assumptions.
Not according to Ingo --- can we get a definitive answer on this,
please?
Many thanks,
Stephen
