In the case of failed mirror group (a group of mirrored segments that
has a segment out of sync that requires user intervention) we need to do
this. At present, we are simply removing/adding mirrors without asking
the user. Novell used to use this method, but customers continually
asked for the ability to make decisions about re-adding failed mirrors
that may come back (it may have been a config error instead of a device
failure, or the RAID array box may have had a unit switched off by
accident when the server booted. A user may also be removing mirrored
devices for archive purposes).
Basically, knowing what these customers already expect, we are reacting
to it before Linux gets to "re-learn" what Novell already knows. There
are many circumstances where the OS needs to be able to ask the user for
a decision about whether a mirrored device should be ignored or re-added
to the mirror group. The distributed cases with mutiple mirrors (we
support up to eight) has split-brain cases to deal with. Out Interface
handles all these wierd cases by simply asking users as to whether a
mirror group will be allowed to go active if any of the mirrors have
come back or gone away during system boot, or whether mirrored segments
that have reappeared should come back.
We also support an automatic mode that just fails out the mirrors and
activates incomplete groups. There can be problems of permanent data
loss in cases where a primary mirror failed, a secondary was elected,
the secondary failed, and now the primary comes back, and the other
mirrors for some reason were remirroring and not all updated (assumes
more than two). In such a case, we will inactivate the mirror group
until we get a human to tell us which segments to coalesce into a mirror
group. We can also do it automatically, and make the best fit choice,
but there could be data loss if the scenario described above happens.
Jeff
Alan Cox wrote:
>
> > these FS's). I basically need this for the utilities that create and
> > config volumes and mirroring so I can query as to whether a file system
> > is mounted from the tools, and prohibit users from blowing away volume
>
> We always configure and create volumes in user space.
>
> > segments, namespaces, etc. while a volume is mounted. There are also
>
> Suppose they as root want to. Thats one of the things with Unix. We stop
> dumb stuff and we stop users trashing the box, but we dont want to be
> stopping users doing damage
>
> > some question/answer stuff during boot from a Netware file system if
> > NWFSCK (Netware volume repair utility) gets invoked due to mounting
> > problems. I need to be able to pass back and forth, such as asking
> > whether an imcomplete mirror group should be activated and failing
> > mirrors dropped during system boot if FS errors are detected.
>
> In the Unix world the tools would be user space. They open the drive and they
> parse the mirror data etc. Then they work directly on /dev/hda or as
> needed in order to fix the data if it needs fixing.
>
> Suppose for example that the drives get shuffled. I know that but the kernel
> doesn't. You will go and try and rebuild the mirror group without me being
> able to stop it. if its in user space I can get out my custom editing toy
> fix it and then fsck the disk.
>
> Similarly in a bad situation I may want to forcibly mount the fs read only
> and unrecovered to make a copy to tape before doing a risky recovery.
>
> Why do you need to trigger this from the kernel side ?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/