[lkml]   [2002]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectMoving a mount point (was Re: Question about pseudo filesystems)
On Saturday 07 September 2002 10:43 pm, Alexander Viro wrote:

> IOW, filesystem shutdown is _always_ a garbage collection - there's nothing
> special about vfsmounts that are not mounted somewhere. Check for fs
> being busy in umount(2) is just a compatibility code - kernel is perfectly
> happy with dissolving mountpoints, busy or not. If stuff mounted is not
> busy it will be shut down immediately, if not - when it stops being busy.

This wanders into something I've been trying to figure out for a while now.

I want to move an existing mount point. I can't unmount it, because it's got
a file open in it, but I want to move it to another binding in the tree and
make the original binding go away so the filesystem IT'S under can go away.
I can create a duplicate binding, but can't get the first binding to go away
while the filesystem's in use.

In case you're curious, the reason is I created a system where the whole root
partition is a zisofs image, with /boot, /etc, /root, and /tmp symlinks to
directories under /var. When the system is fully up, /var will be a mount
point for /dev/hda1 (ext3), and /home on /dev/hda3. / is loopback mounted
from a file ("firmware") under /var.

To make this work, I make an initrd, which mounts /dev/hda1 on /var, does an
losetup on /dev/loop0, exits and lets the boot continue (with root on
/dev/loop0), and then runs /sbin/init-first which does a mount --bind
/initrd/var to /var (duplicating the mount point), and then "exec
/sbin/init", and life goes on. (Obviously, init-first has to run before init
or else /etc is a symlink pointing to nothing. Haven't cleaned up /etc
enough that it can be read-only, not sure I ever will...)

The downside of duplicating the binding in init-first rather than moving it
is I can't unmount /initrd and free its memory. It's not a major burning
issue keeping me awake at night (caffiene manages to do that quite well on
its own, thank you), it's just two extra mount entries in /proc/mounts and
about four megabytes of wasted ram on a system with a quarter gig of the
stuff, but it seems there should be a way to do this...

Since each filesystem only has one superblock (regardless of the number of
mount points), there's no way it can care too deeply about where it's
mounted. The losetup really shouldn't care too much either (fundamentally,
it's bound to an inode). So there's no theoretical reason "mount --move /old
/new" couldn't be made to work. There may need to be a loop to flush
dentries, and some locking, but that would be about it. (Mount points under
the mount point being moved could either be moved as well, or the action
could be denied if any exist. The first is cleaner, it's sort of the
opposite of chroot or pivot_root. P.S. yes, I tried a few variants of
pivot_root, that fails if either of the filesystems has any files open in

It could just be that since the concept of mount point and filesystem
instance were only separated in 2.4, that this is just a historical relic.
If so, I'd like to correct it. A filesystem instance can't go away with an
open file, but a mount point can...

Did I miss the ability to do this already, or are the userspace tools simply
not taking advantage of something the kernel can currently do, or I need to
come up with a patch to make this work under the 2.4 kernel? (I've poked
around a bit, and vfs.txt does a pretty good job of describing how things
were in 2.1.99, back when mount points and filesystem instances were the same


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:28    [W:0.076 / U:0.176 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site