> > Well, usually you mount all your harddisks on bootup, and I
> > don't care if the system seeks a few partitions every five
> > years. :-)
>
> Agreed, but the proposed change was to make ALL mounts be by volume
> name, partition-name, or some indecipherable hex number stored in the
> partition headers, and that idea is a non-starter as far as I'm
> concerned.
Yikes, was someone proposing *that*? I agree that partitions should
continue to be accessed through device files in /dev. UUIDs and labels
shouldn't change that. They should just provide a way of identifying
filesystems at fsck/mount time.
[snip]
> > So why not read in that information once at bootup, act upon it
> > and throw it away after some time or when a program tells us to?
>
> If it's only at boot time, then it's not a problem.
Umm, don't we already have a mechanism to throw the label/UUID data away
after some time? Buffer cache. mount/fsck/whatever reads the file system
superblock, and looks at the label/UUID/whatever. I guess the problem is
when you do a number of consecutive fsck/mounts and the superblocks get
flushed out by the amount of data that fsck reads.
And all "mount -L" does is basically
for partitions listed in /proc/partitions
open the partition (/dev/whatever)
lseek to superblock
read superblock
close
strncmp to see if it's the right one
if it is, mount it, else break
If you're using the Amiga RDB partition table, where there are partition
names in the rigid disk block, fsck/mount could just look at the rigid
disk block on its own to check partition labels. The kernel doesn't need
to get involved.
The only problem with these schemes for normal use is that mounting a root
filesystem is tricky. So initrd is necessary to use labels/UUIDs for
everything.
Brad
-
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/