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 _______________________________________________ busybox mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/busybox
