At Thu, 11 Mar 2010 10:22:29 +0900, Masao Uebayashi
<uebayasi%gmail.com@localhost> wrote:
Subject: Re: (Semi-random) thoughts on device tree structure and devfs
>
> On Thu, Mar 11, 2010 at 4:33 AM, Greg A. Woods <woods%planix.ca@localhost>
> wrote:
> > 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.
>
> While I understand usefulness of human-readable labels, I don't think
> it should be handled in kernel. Because labels are arbitrary. They
> are not ensured to be unique.
The fs_id value is _NOT_ going to be any more unique than the fs_volname
value.
The fs_id value is also not guaranteed to be unique to start with,
especially not across the operational lifetime of a filesystem.
There are a plethora of ways the fs_id can be duplicated, and just about
as many ways for it to get lost (or changed without change control) too.
Sure, labels are arbitrary -- at least to the machine. They are not,
necessarily, arbitrary to the human who creates them though.
In any case the label doesn't have to be _guaranteed_ to be unique to be
useful to both the human and the machine.
Also, the filesystem identifier doesn't have to be a meaningless lengthy
string of impossible to memorize sequences of digits to be useful to the
system either -- a human created, human meaningful, label can be just as
useful to the machine.
> I think labels should be resolved by some name service. It's not
> different than /etc/hosts -> IP address.
Sorry, but I'm flabbergasted! What the heck does that mean in this
context of filesystem identification?
Do you really want to add more complexity, goo, and mess, and places for
errors to happen by adding a translation layer?
First off, there's really nowhere to store your magical mappings.
K.I.S.S. Please!
We do have a place to store a human readable/meaningful filesystem
identifier.
Let the human provide this label.
If the system finds duplicate labels then tell the human which devices
have conflicting labels and where those filesystem were last mounted and
let the human decide which device should be used. (i.e. the labels do
need to be unique for a successful automatic initialisation of the
system, but there needs to be a manual way to work around them not being
unique regardless of what data they consist of)
In my opinion the fs_id value is truly useless anywhere outside of the
on-disk storage of a single filesystem copy where its sole valid use is
(IIUC) to help to match valid backup superblock copies. The fact I'm
not even sure it's safe or sane to derive the NFS filesystem filehandle
from it in any way.
--
Greg A. Woods
Planix, Inc.
<woods%planix.com@localhost> +1 416 218 0099 http://www.planix.com/
Attachment:
pgpVlcpPReYPQ.pgp
Description: PGP signature