My brain hurts. (Messing with mount.)

[Denis Vlasenko]

On Monday 06 March 2006 03:07, Rob Landley wrote:
> There is no mount spec.  Only endless questions.
> 
> It is possible to --bind mount a directory onto itself.  (Oddly, the system 
> survived.  It seems to be a NOP, I could still list the contents of the 
> directory, but it shows up in /proc/mounts.)

With upcoming kernel support, this will allow making subrees RO
(or noatime, noexec etc) if you use corresponding mount option.

> Judging by what the gnu one does for "mount -a /dev/hda" and "mount 
> -a /dev/hda /thingy", the -a should be silently dropped when you supply 
> blockdev and/or directory arguments.
> 
> When to take absolute paths of things and when to preserve relative paths is 
> confusing.  (Yes, you can have relative paths such as "../woot" in fstab.)  

Wow

> Some things (calling losetup ioctls, creating an entry in /etc/mtab) insist 
> on an absolute path.  Other times the "blockdev" argument is a comment, or 
> something else entirely (such as a network address, or an MTD device 
> identifier) and taking the absolute path would screw things up.  For 
> iterating through /etc/fstab, I need to check for matches against _both_,
> because /etc/fstab doesn't just have /dev/hda1, it can also have something 
> like:
>   walrus.img    walrus   ext2 loop,ro
> 
> Which can be mounted via:
>   mount walrus.img
> But not via:
>   mount ./walrus.img  # Still expects "walrus" in the current directory...

Bizarre

> Oddly, after mounting that, I can umount ./walrus.img and it works.

I think that "umount something" basically shall simply call
oldumount("something") syscall, literally passing "something" as an argument.

Should umount do "ulosetup" as well? Maybe something like this:
1) scan /etc/mtab (or /proc/mounts), if entry exists and has "loop" option,
   remember that.
2) call oldumount, exit if not successful
3) if there was a "loop" entry: rescan /etc/mtab (or /proc/mounts),
   if entry is gone, then delete loop device.

> When you supply two arguments, mount doesn't check fstab at all.  With the 
> above fstab entry:
>   mount walrus.img walrus
> 
>   The mount is rw, not ro, and I have to say -t ext2 -o loop with the gnu
>   mount.

Makes sense

> "mount -o remount,rw" does require at least one argument.

Makes sense too. More to it, passing _two_ arguments would be rather confusing.

> Using the above fstab entry, and doing this:
>   mount walrus.img walrus
>   mount -o remount,rw walrus
> Complains that block device walrus.img is write protected, and it's mounting 
> read only.  (Understandable, since it did a read-only association on the 
> loopback device.)

Probably best to try rw losetup, but ro mount. Allows for remount,rw.

> Following up with
>   mount -o remount,rw /dev/does-not-exist walrus
> Complains that /dev/does-not-exist is mounted read only.  Amusing. :)

Two-argument remount makes little sense for me. There must be one argument -
a mountpoint.

Can we just print an error message and exit? (OTOH I fear there are
init scripts from hell which will be upset...)

> Ooh, if I add an entry:
>   /path/to/walrus.img potato ext2 loop,rw 1 2
> 
> Then _that_ always resolves the paths, and can be mounted via a relative path.  
> (In fact if _both_ are in there, that one wins even if it's after the first 
> one.  Strange.)  Right, my brain hurts.
> 
> I consider "mount -t procfs /dev /proc" and then trying to umount /dev to be a 
> "doctor, it hurts when I do this" case.
> 
> Apparently, when you mount a symlink on another symlink, the kernel 
> dereferences both for you, which makes sense I suppose.  (Of course this is 
> another case where /etc/mtab can get confused...)

I'm glad someone is trying to sanitize this mess.
Thanks Rob!
--
vda