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
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo [at] vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

"Mike Snitzer" <snitzer [at] gmail.com> 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 [at] vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

On 10/18/07, Goswin von Brederlow <brederlo [at] informatik.uni-tuebingen.de> wrote:
> "Mike Snitzer" <snitzer [at] gmail.com> 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.

Both of your examples are fairly tenuous given that such members
shouldn't have been provided on the --asemble commandline. I'm not
talking about auto assemble via udev or something. But auto assemble
via udev brings up an annoying corner-case when you consider the 2
cases you pointed out.

So you have valid points. This leads to my last question; having the
ability to _optionally_ tolerate (repair) such stale members would
allow for greater flexibility. The current behavior isn't conducive
to repairing unprotected raids (that mdadm/md were told to assemble
with specific members) without taking steps to say "no I really
_really_ mean it; now re-add this disk!".

Any pointers from Neil (or others) on how such a 'repair "non-fresh"
member(s) on assemble' override _should_ be implemented would be
helpful. My first thought is to add a new superblock
--update=repair-non-fresh option to mdadm that would tie into a new
flag in the MD superblock. But then it begs the question: why not
first add support to set such a superblock option at MD create-time?
The validate_super methods would also need to be trained accordingly.

regards,
Mike
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo [at] vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html