tech-userlevel archive

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

Re: mounting wedges by name



On Sun, Oct 17, 2010 at 01:43:40PM +0200, Michael van Elst wrote:
> On Sun, Oct 17, 2010 at 01:14:08PM +0200, Martin Husemann wrote:
> > Looks good, but could we also have a UUID=... variant to refer to the
> > GUID always (instead of the name)?
> > 
> > I know that this would require a new dkioctl, or extending struct 
> > dkwedge_info.
> 
> What would be the advantage of always allowing a UUID? If you want
> to use UUIDs you can do that by not naming the partitions.
> 
> You already named the drawback, it is incompatible and unlikely
> suited for a pullup to older NetBSD releases.

Besides UUID and name, there are other volume properties that it would
be nice for mount(8)/fstab(5) to match on, and there will probably be
more properties in the future.

What if you allow properties to be named by dotted keywords, and reserve
the wedge. space for dkwedge_info?

        uint8_t         dkw_wname[128]; /* wedge name (Unicode, UTF-8):
                                         * wedge.name
                                         */
        char            dkw_parent[16]; /* parent disk device name:
                                         * wedge.parent
                                         */
        daddr_t         dkw_offset;     /* LBA offset of wedge in parent:
                                         * wedge.offset
                                         */
        uint64_t        dkw_size;       /* size of wedge in blocks: wedge.size
                                         */
        char            dkw_ptype[32];  /* partition type string: wedge.type */

Let all other keywords indicate device properties (drvctl -p dk0).
E.g., for a GPT partition[1], let us flesh out the wedge properties
with information such as partition type GUID, unique partition GUID,
and partition name.

The wedge. space will work for -current, past, and future releases. All
other keywords will work for -current and future releases.

Dave

[1] 
http://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_entries_.28LBA_2.E2.80.9333.29

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


Home | Main Index | Thread Index | Old Index