cvs commit: src/sys/amd64/conf GENERIC src/sys/i386/conf GENERIC src/sys/ia64/conf GENERIC src/sys/pc98/conf GENERIC src/sys/powerpc/conf GENERIC src/sys/sparc64/conf GENERIC src/sys/sun4v/conf GENERIC

[John-Mark Gurney]

Pawel Jakub Dawidek wrote this message on Sat, Feb 10, 2007 at 12:34 +0100:
> On Fri, Feb 09, 2007 at 01:15:17PM -0800, John-Mark Gurney wrote:
> > Brooks Davis wrote this message on Fri, Feb 09, 2007 at 19:03 +0000:
> > > brooks      2007-02-09 19:03:18 UTC
> > > 
> > >   FreeBSD src repository
> > > 
> > >   Modified files:
> > >     sys/amd64/conf       GENERIC 
> > >     sys/i386/conf        GENERIC 
> > >     sys/ia64/conf        GENERIC 
> > >     sys/pc98/conf        GENERIC 
> > >     sys/powerpc/conf     GENERIC 
> > >     sys/sparc64/conf     GENERIC 
> > >     sys/sun4v/conf       GENERIC 
> > >   Log:
> > >   Include GEOM_LABEL in GENERIC.  It's very useful and not well publicized
> > >   enough.
> > >   
> > >   Approved by:    pjd
> > 
> > Can anyone think of a good place to put a warning about using labels
> > along w/ gmirror?  I've had a case recently where I was loading g_label,
> > but forgot to load g_mirror...  Since I was using ufs labels, my fs
> > mounted perfectly fine, but was mounting only one part of the g_mirror..
> > I finally found this out when g_label decided to randomly use the other
> > disk one boot...
> > 
> > Maybe g_label should not expose duplicate labels?
> 
> It only expose one of them - the one which comes first...
> I'd prefer not to destroy existing provider when duplicated entry
> appears. Imagine a situation where you have perfectly running system
> with root mounted from /dev/ufs/root and at some point you insert
> USB Pendrive with a UFS file system, which also has "root" label.
> Do you really want the ufs/root provider from under your root file
> system to be destroyed?

Considering that the provider mounted as root has an exclusive bit
set, you can easily detect this case, and not destroy it...  In my
case, both labels are unopened, and there are no open references to
them...

> Not loading gmirror was configuration mistake. I do want to protect
> users against such mistakes, but in this situation I think the mistake I
> described is more common or can be more problematic.

And can easily be detected, and happens at a different point than the
issue that I'm complaining about...

> If you set kern.geom.label.debug to >= 1, glabel will print a warning:
> 
> Label root(ufs/root) already exists (/dev/ad0s1a).
> 
> (or something like that). We may consider printing it at the default
> debug level (0) and see if there are not too many reports from the users
> with false-positives.

Printing a debug still doesn't prevent the automatic mounting and
corruption of the mirror...

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."