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

[Pawel Jakub Dawidek]

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?

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.

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.

-- 
Pawel Jakub Dawidek                       http://www.wheel.pl
pjd at FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-src/attachments/20070210/d0b86092/attachment.pgp