mount -a remounts tmpfs entries: bug or feature?

[Rob Landley]

On Tuesday 25 November 2008 04:48:04 Denys Vlasenko wrote:
> On Tuesday 25 November 2008 08:16, Roy Marples wrote:
> > On Tue, 2008-11-25 at 03:04 +0100, Denys Vlasenko wrote:
> > > On Monday 24 November 2008 10:21, Ralf Friedl wrote:
> > > > Vladimir Dronnikov wrote:
> > > > >     > run 'mount -a' over and over you get stacking mounts
> > > > >
> > > > > Personally, I'd like to be able to mount valid stuff the way I
> > > > > wish. So BB behaves right.
> > > >
> > > > For a manual mount, I agree.
> > > > But I think 'mount -a' should mount everything from /etc/fstab,
> > > > unless it is already mounted.
> > >
> > > Define "already mounted". It's not trivial.
> >
> > The canonical entry exists in mtab and matches mnt_dir and is of
> > mnt_type.
> > The code in util-linux does this.
> > FWIW, the BSD mount does the same thing (although it doesn't use mtab).
>
> Should mount options match? Should order of mount options match?

Order of mount options is never relevant, and there's at least one filesystem 
(vfat) that spits back default mount options (I.E. ones you didn't provide it) 
when you query /proc.  (There are string options and flag options, and you 
have to edit out the flag options from the option string not only to set the 
appropriate bits in the flag field but because some filesystems barf on 
unknown options and which includes seeing things like "noatime" in their 
option string...)

http://lkml.indiana.edu/hypermail/linux/kernel/0705.1/3447.html

Maintaining your own /etc/mtab is no longer an interesting case, on modern 
Linux you should let the kernel do that for you via /proc/mounts.  (This was 
true because of "chroot" long before containers or per-process mounts made it 
moreso.)

The continued existence of code to maintain an /etc/mtab is a hack for people 
who want to remove procfs from their system for size reasons, and this 
is pretty much expected to cost them functionality.  (You can't implement "ps" 
these days without it.)

> What if fstab specifies "mount /dev/sdb1 on /usr and /dev/sdb2 on
> /usr/storage" and we find that /dev/sdb2 is mounted on /usr/storage,
> but /dev/sdb1 is not mounted? Should we mount /dev/sdb1?
> But that will "cover" /usr/storage mountpoint!

Did you try it?  A lot of those cases turn out to be nontrivial and non-
obvious.

A lot of the kernel's mount stuff seems to work by string matching of absolute 
path from the root rather than by inode.  I tried hard to create a "recursive 
mount" using --bind mounts and it turns out you can't:

http://lkml.indiana.edu/hypermail/linux/kernel/0605.1/2329.html

In this case, the question to ask is "how did you get into that circumstance 
in the first place".  If your fstab entries are out of order, that's a bug in 
your fstab.  If you mount some stuff by hand and then do a mount -a, the mount 
-a is not expected to be psychic.

The common case is that fstab has /dev/shm and such in it, which is what tmpfs 
was invented for.  Most filesystems under 2.5 and up share superblocks, so 
mounting them in multiple places acts a bit like a --bind mount, it just makes 
the same directory show up in more than one place (this is the "shared 
superblock" stuff).  But ram backed block devices (ramfs and tmpfs) are weird: 
every instance has a new superblock.  If you want to mount the same one twice, 
you _do_ use --bind on an existing instance of the sucker.  (I dunno what 
would happen if you mount -t tmpfs, --bind mount that, and then umount the 
first instance of it.  I'd guess either the umount would say it's busy or 
reference counting would make it all gracefully work with the possible 
exception that /proc/mounts would have strange stuff in it.  I haven't tried.)

If it sounds like every time I think about this stuff I come up with another 
strange corner case whose behavior I'd have to determine experimentally, it's 
because it's true. :)

Rob