tech-userlevel archive

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

Re: mounting by wedge name



On Wed, Mar 11, 2009 at 08:53:18PM -0400, Thor Lancelot Simon wrote:
> On Wed, Mar 11, 2009 at 07:13:22PM -0500, David Young wrote:
> > I am reopening this discussion because a year has past, and we are still
> > without devfs or mount by wedge id, and I desperately want one or the
> > other.  More remarks in-line:
> > 
> > On Thu, Jan 10, 2008 at 01:09:25PM -0800, Jeff Rizzo wrote:
> > > Bill Stouder-Studenmund wrote:
> > >> On Sun, Dec 23, 2007 at 01:49:53PM -0800, Jeff Rizzo wrote:
> > >>   
> > >>> Certainly, I could see devfs removing the need for a lot of this - which
> > >>> would make me happy.  Meanwhile...
> > >>>     
> > >>
> > >> mjf's chimmed in, indicating something will happen w/ devfs. I've been  
> > >> helping him with it, and wedges are the main reason I want devfs.
> > >>   
> > >
> > > Yes, I think it makes sense to wait - especially since I found a number  
> > > of other cases I would have had to deal with.
> > 
> > Jeff, do you remember what those other cases are?
> 
> Some of the wedge discovery methods false positive, making it impossible
> to use disks that actually have partition tables of other types.
> 
> Patient zero for this syndrome is the GPT method, which falses positive
> on disks that once had a GPT but are now MBR partitioned with a BSD
> disklabel in an MBR partition, making systems that ran fine this way
> with 4.0 suddenly fail when upgraded because the system finds dk0
> instead of wd0 and does not enumerate wd0's disklabel partitions.

A comment in dkwedge_discover_gpt() may indicate that GPT support
is not finished?

        /*
         * Note: We don't bother with a Legacy or Protective MBR
         * here.  If a GPT is found, then the search stops, and
         * the GPT is authoritative.
         */

IIUC, the MBR method matches with higher priority than BSDLABEL,
and BSDLABEL matches with higher priority than GPT.  Does it help to add
options DKWEDGE_METHOD_BSDLABEL and DKWEDGE_METHOD_MBR to the kernel
configuration?

I don't understand why BSDLABEL and MBR methods are not enabled by
default; the comment in sys/arch/i386/conf/GENERIC says

# The following two options can break /etc/fstab, so handle with care
#options        DKWEDGE_METHOD_BSDLABEL # Support disklabel entries as wedges
#options        DKWEDGE_METHOD_MBR      # Support MBR partitions as wedges

I guess that opening device wd0x is not allowed if a wedge is configured
on the same extent of wd0, or if any wedge at all is on wd0?

> There's also the problem with the original syntax for mount-by-wedge-id
> making NFS filesystems from hosts named "wedge" fail.  I've worked two
> places that had fileservers named "wedge"; anyway, backwards compatibility
> failures like that are bogus.

I think that the %keyword:value syntax that I suggested fixes this, and
it is more flexible: we can match on any number of properties.

Dave

-- 
David Young             OJC Technologies
dyoung%ojctech.com@localhost      Urbana, IL * (217) 278-3933


Home | Main Index | Thread Index | Old Index