tech-kern archive

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

Re: (Semi-random) thoughts on device tree structure and devfs



At Wed, 10 Mar 2010 08:56:36 +0000 (GMT), Iain Hibbert 
<plunky%rya-online.net@localhost> wrote:
Subject: Re: (Semi-random) thoughts on device tree structure and devfs
> 
> So, you want to be able to mount a disk by the label:
> 
>   $ mount -t msdosfs -o label "foobar" /external_disk_foobar

Yes, something like that, using fs_volname of course.  I've wanted this
kind of feature for decades.

And of course all the other filesystem tools should have this interface
as well.  It's no good if it's not uniformly usable.  newfs and tunefs
need to be able to set and change fs_volname to start with.  Disk tools
could be made to work with disk label names too for added fun, but let
us not confuse fs_volname with pack names, disklabel names, etc.

Naturally this should not replace the use of the device file, but rather
be added in addition to it, as an optional way to specify the ultimate
device used to access the filesystem.

In fact I'd much rather see lots of work go into this feature than into
anything even remotely related to devfs.

BTW, we don't want to end up with the horrid mess some GNU/Linux systems
now use when their kernel config's specify root=LABEL=xxx -- I think we
can do much better.


> or, if you know the UUID
> 
>   $ mount -t msdosfs -o uuid 3478374923723423 ~/thumb_drive

I think UUID's, as I understand them so far (fs_id, right?), are really
too fragile, too meaningless and difficult to read, and too dangerous,
to use for this purpose.

They are not actually unique, to start with, so labelling them so is
just plain wrong.

Search google for Russell Coker's discussion on Label vs. UUID.

Filesystem volume names can be said to have many of the same problems,
except to start with we know and understand that they're not unique
right off the bat, and we can assign human meaning to them and make them
memorable.

Let's at least get filesystem access by volume names working right, then
we can go on to think about other things, if they still seem worthwhile.

-- 
                                                Greg A. Woods
                                                Planix, Inc.

<woods%planix.com@localhost>       +1 416 218 0099        http://www.planix.com/

Attachment: pgpYOWXNn94M9.pgp
Description: PGP signature



Home | Main Index | Thread Index | Old Index