On 11 Jan 00 at 22:24, Stephen C. Tweedie wrote:
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.
Hi Stephen,
I did not follow this thread (on -fsdevel) too close (and I never
looked into RAID code, so I should shut up), but... can you
confirm that after buffer with data is finally marked dirty, parity
is recomputed anyway? So that window is really small and same problems
occurs every moment when you wrote data, but did not wrote parity yet?
Thanks,
Petr Vandrovec
[EMAIL PROTECTED]
