Linus: below is what I plan on doing for adding volume label
support. Could you please comment?
Andries Brouwer writes:
> On Thu, Apr 13, 2000 at 11:53:35AM -0600, Richard Gooch wrote:
> > Alan Cox writes:
>
> > > UUID solves all the interesting cases.
>
> > Actually, you want labels too: they're more friendly.
>
> Not so many people actually use the possibility to mount by volume
> label or UUID as it exists today. One of the criticisms is that this
> is ext2-specific. So I wrote some stuff for arbitrary
> filesystems. Clearly, in the general case, the label must live
> outside the filesystem. Since there is no room in the partition
> table either I made a Linux disk label that lives in disk sectors
> 1-3 (and either adds to or replaces the DOS-type partition table).
This is quite interesting. But...
> Kernel support has been available now for quite some time already
> (I mean the blkpg stuff) but so far no-one has stated the desire
> to actually use this.
Wouldn't this require people to change over to your new partition
scheme? That would involve a lot of pain. Also, what about dual-boot
systems?
BTW: what's the config option to turn this on?
> > And you shall have them both. /dev/volumes is coming.
>
> With what contents? Obtained how?
What will happen is that (names may be changed) /dev/volumes/uuids/
will contain a symlink for each partition/MD with a UUID. The name of
the symlink will be the UUID "string" and it will point to the "real"
device node (under /dev/scsi/ for example).
/dev/volumes/labels/ will be similar, except that it will have the
human-friendly labels as the symlink names.
For further details, extracted from a private email:
I'm only proposing a very thin layer in the kernel. Just enough to
expose the label names and UUIDs to user-space. Anything more
sophisticated would be built on top of that, probably in
user-space.
OK, on to the specifics of what needs to be done:
- define new test_super() FS method which is used to test if the FS
recognised it's signature in the block device
- move existing FS detection code in each FS out of the read_super()
method and into the test_super() method
- modify VFS to call test_super() before read_super() method
- define new read_labels() FS method which is used to read label and
UUID from FS superblock
- implement read_labels() method for each FS which has lables and/or
UUIDs
- modify fs/partitions/check.c:devfs_register_partition() to call
the test_super() method for each registered FS until one succeeds,
at which point it calls the read_labels() method for that FS and
registers entries (symlinks) in /dev/volumes/
- testing.
None of this is all that complicated, and some of it (the separation
of FS testing code from read_super() methods) has been suggested
before on linux-kernel (although no-one bothered to do it). The
intention of others was to support automatic FS module loading.
Regards,
Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Apr 15 2000 - 21:00:23 EST