Andries Brouwer writes:
> 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.
So what's the interaction. How does it work?
> BTW: what's the config option to turn this on?
>
> It is already turned on, there is no config option.
So how exactly does this work? Do you just need a new version of fdisk
to create a different type of partition table?
> 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".
We already have those heuristics. For the purposes of label hunting,
we can also check the partition type.
> [Digression: have you seen what mount does in mount_guess_fstype.c?
> Such a strange collection of heuristics does not belong in the
> kernel.]
It does if you want to mount the root FS and not *have* to specify the
FS type.
> (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.
It's not messy. No more messy than the FS-specific code we have in
each FS. Each FS can export what it has (if anything) in a format
expressable in ASCII.
> 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.
But then you can't mount the root FS without using initrd. People
complain about devfs being forced down their throat, but I don't want
initrd to be forced down my throat either. It's such an awkward thing
to deal with. You end up with a split-personality machine, because you
need a collection of programmes and configuration files duplicated in
the initrd and in the real root FS. Ugh!
Forcing everything into initrd, for the sake of stripping the kernel,
is the wrong way to go. It makes the overall system more complex.
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:26 EST