Re: kicking non-fresh member from array?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



"Mike Snitzer" <snitzer@xxxxxxxxx> writes:

> All,
>
> I have repeatedly seen that when a 2 member raid1 becomes degraded,
> and IO continues to the lone good member, that if the array is then
> stopped and reassembled you get:
>
> md: bind<nbd0>
> md: bind<sdc>
> md: kicking non-fresh nbd0 from array!
> md: unbind<nbd0>
> md: export_rdev(nbd0)
> raid1: raid set md0 active with 1 out of 2 mirrors
>
> I'm not seeing how one can avoid assembling such an array in 2 passes:
> 1) assemble array with both members
> 2) if a member was deemed "non-fresh" re-add that member; whereby
> triggering recovery.
>
> So why does MD kick non-fresh members out on assemble when its
> perfectly capable of recovering the "non-fresh" member?  Looking at
> md.c it is fairly clear there isn't a way to avoid this 2-step
> procedure.
>
> Why/how does MD benefit from this "kicking non-fresh" semantic?
> Should MD/mdadm be made optionally tolerant of such non-fresh members
> during assembly?
>
> Mike

What if the disk has lots of bad blocks, just not where the meta data
is? On every restart you would resync and fail.

Or what if you removed a mirror to keep a snapshot of a previous
state? If it auto resyncs you loose that snapshot.

MfG
        Goswin
-
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

[Index of Archives]     [Linux RAID Wiki]     [ATA RAID]     [Linux SCSI Target Infrastructure]     [Linux Block]     [Linux IDE]     [Linux SCSI]     [Linux Hams]     [Device Mapper]     [Device Mapper Cryptographics]     [Kernel]     [Linux Admin]     [Linux Net]     [GFS]     [RPM]     [git]     [Yosemite Forum]


  Powered by Linux