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

[David Newall <david@davidnewall.com>]

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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/