Re: RFC: permit link(2) to work across --bind mounts ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



dean gaudet wrote:
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)

Whatever security /home has, /var/home is the one that restricts because users can still access their files that way.

- 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 try to balance disk space between /var and /home
- i didn't want to use a volume mgr just to handle disk space balance...

Pffuff. That's what volume managers are for! You do have (at least) two independent spindles in your RAID1 array, which give you less need to worry about head-stack contention. You probably want different mount restrictions on /home than /var, so you really must use separate filesystems. LVM is your friend.

But with regards to bind mounts and hard links: If you want to be able to hard-link /home/me/log to /var/tmp/my-log, then I see nothing to prevent hard-linking /var/home/me/log to /var/tmp/my-log.

I think it's possible to be too precious about preserving the illusion of one file-system structure when the reality is something different. Don't lose site of reality.
--
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]
  Powered by Linux