[ On Tue, October 6, 1998 at 13:12:27 (-0400), der Mouse wrote: ]
> Subject: Re: Another changer, another changer problem
>
> >>> [...] is clearly the better approach.
> >> It's better - in some cases.  It's also worse - in other cases.
> > I think it is *always* the better approach,
> 
> As a simple example of a case where it's worse than the current
> approach, "why should all of a sudden /usr fail to mount just because I
> hauled a scratch disk out of my spare disk pile and connected it?  Oh
> fsck, right, it had /usr from that other system on it briefly...".  Or
> worse, there are disambiguating rules that choose the new disk's /usr
> and "what the h311 do you mean /usr/bin is suddenly full of sun3
> binaries instead of sparc binaries?!".

Those are all problems that can be avoided by a good and clean design of
this feature, and with careful use of naming conventions (which implies
that the label needs to be big enough to include all the information
that might be deemed important to disambiguate it from other entries).

> > however....
> >> It would be a good thing to have available.  It would be an
> >> extremely obnoxious thing to have no alternative to.
> > I think the current existing approach offered by mount(2) is very
> > much an acceptable alternative.
> 
> Then I think we are in furious agreement, lacking only
> 
> - Either decide to use the last-mounted-on string from the superblock
>    or find a place to stash the filesystem label string (I see no
>    reason not to go with the former)

There are at least three problems with using the "last-mounted-on" string.

1. it would be throwing away useful information and potentially changing
   something defined by the administrator.  This string should always be
   updated at *unmount* time.  This alone doesn't rule out its use, but
   the "partition label" string should never be updated automatically --
   it must be updated only by a user with write access to the raw disk
   (or at least to the partition table), and only under explicit manual
   control.

2. this field is currently not part of the partition table and is not
   long enough to disambiguate paths with the same terminal directory
   name.  I don't even think a field with the semantics
   "last-mounted-on" should be in the filesystem -- it should be in the
   label.  Relying on the filesystem structure to include this
   information is wrong and cannot be guaranteed.  I don't know what to
   do about the size problem though, without simply expanding it to a
   "decent" length (256?).  [in addition there are things in the current
   partition table that I think really belong in the filesystem!]

3. this implies the wrong semantics in the first place.  The "label"
   should be a unique string that is only related to the mount point by
   some table such as /etc/fstab.  The label should *not* be the
   basename of the mount directory itself.  This will help to avoid most
   of the messy problems you describe above.  If/when someone implements
   such a scheme the should document these rules of thumb so that
   admins and operators won't make mistakes that will lead to confusion.

> - An interface so that mount(8) can get a list of all disks on the
>    system (to go searching for filesystems on) - anyone for
>    /kern/disks/? :-)

This might be an OK approach, but I'd prefer a mountbylabel() system
call, or a unique flag for the existing mount(2) which would tell the
kernel to treat the "data" as a label name, not a special file
pathname.

Some way for the user to inspect labels without needing read access to
the raw device is in itself a good idea, and a kernfs "disks" directory
with appropriate information in it is as good an approach as any and
certainly preferred by anyone who likes the "everything's a file"
approach.

> - A way to resolve ambiguities, or else decide to just error out (but
>    remember that when multiple partitions begin at the same place, they
>    will appear to contain the same superblock)

agreed.

> - A command-line syntax to mount(8) to have it find the filesystem
>    device by filesystem label instead of /dev name, and a companion
>    syntax for fstab

agreed.

> - Someone to actually implement it
> 
> I am emphatically not volunteering for any of this.  (I may implement
> /kern/disks, if only because it sounds like a cool idea on its own.  If
> I do I'll let it be known.)

me neither -- at least not anywhere near the top of my so-called "todo"
list without further incentive!  ;-)

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>