From rgooch@vindaloo.ras.ucalgary.ca Fri Apr 14 05:48:27 2000
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?
No. Zero pain. No problems with multible boot systems.
BTW: what's the config option to turn this on?
It is already turned on, there is no config option.
[You see, I believe in adding power that can be used but is invisible
when it is not used. That is why I complained that it is a mistake
to automatically mount devfs on /dev. Indeed, devfs is far from invisible.]
> > 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/
Hmm. (i) test_super() - that is the first part of the present
read_super(). Note that I have seen several times the situation
where more than one test_super() would succeed. It seems to me
that it is a bad idea to introduce FS methods that are somewhat
vague heuristics only. How do you recognize an msdos fs? There
is no good test. The conclusion can only be that each fs is allowed
to implement test_super() by "return TRUE".
[Digression: have you seen what mount does in mount_guess_fstype.c?
Such a strange collection of heuristics does not belong in the kernel.]
(ii) "implement read_labels() method for each FS which has
lables and/or UUIDs." - this gets messy, since the format of
the various labels and numbers varies quite a lot.
Sometimes binary, sometimes ASCII. Sometimes there are several
types of labels. Sometimes there is nothing at all.
I don't think this sounds like a good plan. Moreover, it seems
to me that all you would obtain by doing this is already
possible today - no kernel changes required.
This BLKPG_ADD_PARTITION stuff is rather powerful. You can add
and delete partitions on the fly. No kernel parsing partition tables
is needed, userspace tells the kernel where the partition starts,
how large it is, what labels it has.
There is a little user space support, mostly in the form of
tiny proof-of-concept utilities (see, e.g., addpart.c and partx.c
in the util-linux distribution - Adam Richter reported success in
booting a kernel that did not have any partition reading code itself),
but as soon as people start to actually use this, the support will
increase.
Andries
-
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:24 EST