On Monday November 27, [EMAIL PROTECTED] wrote:
> On Mon, Nov 27, 2000 at 02:41:53PM +1100, Neil Brown wrote:
> > raid5 rebuild has been fatally flawed ever since it got into 2.4,
> > Please apply the following patch.
> >
> > Thanks,
> > NeilBrown
> >
> > --- ./drivers/md/raid5.c 2000/11/27 02:46:45 1.1
> > +++ ./drivers/md/raid5.c 2000/11/27 02:47:37 1.2
> > @@ -1516,8 +1516,8 @@
> > raid5_conf_t *conf = (raid5_conf_t *) mddev->private;
> > struct stripe_head *sh;
> > int sectors_per_chunk = conf->chunk_size >> 9;
> > - unsigned long stripe = (block_nr<<2)/sectors_per_chunk;
> > - int chunk_offset = (block_nr<<2) % sectors_per_chunk;
> > + unsigned long stripe = (block_nr<<1)/sectors_per_chunk;
> > + int chunk_offset = (block_nr<<1) % sectors_per_chunk;
> > int dd_idx, pd_idx;
> > unsigned long first_sector;
> > int raid_disks = conf->raid_disks;
> > -
> I have a filesystem on 6 disk 230GB RAID-5
>
> Two questions:
> 1) Is it safe to recompile the currently running kernel with the above patch
> applied and reboot the new kernel?
Yep. Definately safe. Recommended even.
> 2) As I understand it, the effect of the bug is that in case a disk really
> fails, the reconstruction of data doesn't work. How do I force a rebuild
> of the array once the patched kernel is running?
It's a bit more subtle than that. Actually, reconstruction after a
failure is the case that the old code is most likely to get right!
The purpose of the code with the error is to determine which block of
a given stripe is the parity block. The old code gets it wrong.
This has a few different effects:
1/ when checking parity after an unclean shutdown, or at device
initialisation time: if a stripe with incorrect parity is found
the parity will be corrected by updating the block which is
thought to be the parity block. If this is the wrong block, then
random data will get corrupted.
2/ If normal i/o is happening on a stripe that is having it's parity
checked or corrected, then that normal I/O will get confused by
having the parity block number (pd_idx) change underneath it.
This can lead to a BUG() or other odd thing.
How do you force a rebuild? It's a bit awkward.
One way is to fail, remove, and then add a drive (using
raid_setfaulty, raid_hotremove, raid_hotadd). This will cause data
and parity to be rebuilt on that drive. This will leave you
vulnerable until the rebuild finishes, as a drive failure will kill
the array.
Another way is to recreate the array with mkraid. Providing that you
get the configuration exactly the same, your data will still be there,
but it will start checking parity.
The danger in this is that if you get the configuration wrong, you
could scramble your data.
Finally, you could unmount your filesystem, sync your drives, and
powercycle your machine. This will leave the data on the raid array
safe, but marked dirty. A parity check will then happen at restart.
It would be nice to be able to check parity more directly. I will put
this on my todo list.
NeilBrown
>
>
> Nils
>
> --
> *New* *New* *New* - on shellac records
> Windows HE - see top 10 reasons to downgrade on
> Historical Edition http://www.microsoft.com/windowshe
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to [EMAIL PROTECTED]
