On Wed, 19 Dec 2007, David Newall wrote:
> Mark Lord wrote:
> > But.. pity there's no mount flag override for smaller systems,
> > where bind mounts might be more useful with link(2) actually working.
>
> I don't see it. You always can make hard link on the underlying filesystem.
> If you need to make it on the bound mount, that is, if you can't locate the
> underlying filesystem to make the hard link, you can use a symbolic link.
i run into it on a system where /home is a bind mount of /var/home ... i
did this because:
- i prefer /home to be nosuid,nodev (multi-user system)
- i prefer /home to not be on same fs as /
- the system has only one raid1 array, and i can't stand having two
writable filesystems competing on the same set of spindles (i like to
imagine that one fs competing for the spindles can potentially result
in better seek patterns)
- i didn't want to do /var -> /home/var or vice versa ... because i don't
like seeing "/var/home/dean" when i'm in my home dir and such.
- i didn't want to try to balance disk space between /var and /home
- i didn't want to use a volume mgr just to handle disk space balance...
so i gave a bind mount a try.
i was surprised to see that mv(1) between /var and /home causes the file
to be copied due to the link(1) failing...
it does seem like something which should be configurable per mount
point... maybe that can be done with the patches i've seen going around
supporting per-bind mount read-only/etc options?
-dean
p.s. in retrospect i probably could have arranged it more like this:
mount /dev/md1 $tmpmntpoint
mount --bind $tmpmntpoint/var /var
mount --bind $tmpmntpoint/home /home
umount $tmpmntpoint
except i can't easily specify that in fstab... and neither of the bind
mounts would show up in df(1). seems like it wouldn't be hard to support
this type of subtree mount though. mount(8) could support a single
subtree mount using this technique but the second subtree mount attempt
would fail because you can't temporarily remount the device because the
mount point is gone.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
