On Tue, Oct 21, 2008 at 3:38 AM, David Greaves <david@xxxxxxxxxxxx> wrote: > Mario 'BitKoenig' Holbe wrote: >> Jon Nelson <jnelson-linux-raid@xxxxxxxxxxx> wrote: >>> I was wondering about proactive drive replacement. >> [bitmaps, raid1 drive to replace and new drive, ...] >> >> I belive to remember a HowTo going over this list somewhere in the past >> (early bitmap times?) which was recommending exactly your way. >> >>> The problem I see with the above is the creation of the raid1 which >>> overwrites the superblock. Is there some way to avoid that (--build?)? >> >> You can build a RAID1 without superblock. > > How nice, an independent request for a feature just a few days later... > > See: > "non-degraded component replacement was Re: Distributed spares" > http://marc.info/?l=linux-raid&m=122398583728320&w=2 D'oh! I had skipped that thread before. There are differences, however minor. > It references Dean Gaudet's work which explains why the above scenario, although > it seems OK at first glance, isn't good enough. > > The main issue is that the drive being replaced almost certainly has a bad > block. This block could be recovered from the raid5 set but won't be. > Worse, the mirror operation may just fail to mirror that block - leaving it > 'random' and thus corrupt the set when replaced. > Of course this will work in the happy path ... but raid is about correct > behaviour in the unhappy path. In my case I was replacing a drive because I didn't like it. -- Jon -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
