linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Newall <david@davidnewall.com>
To: dean gaudet <dean@arctic.org>
Cc: Mark Lord <lkml@rtr.ca>, Al Viro <viro@ftp.linux.org.uk>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: RFC: permit link(2)  to work across --bind mounts ?
Date: Sat, 29 Dec 2007 18:59:44 +1030	[thread overview]
Message-ID: <47760578.2090305@davidnewall.com> (raw)
In-Reply-To: <alpine.DEB.0.999999.0712281835240.5207@twinlark.arctic.org>

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.

  parent reply	other threads:[~2007-12-29  8:29 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-18 22:46 RFC: permit link(2) to work across --bind mounts ? Mark Lord
2007-12-18 22:57 ` Mark Lord
2007-12-18 23:00 ` Al Viro
2007-12-18 23:14   ` Al Viro
2007-12-19  3:54     ` Mark Lord
2007-12-19  3:59       ` David Newall
2007-12-19 16:47         ` Mark Lord
2007-12-19 18:38           ` David Newall
2007-12-29  2:53         ` dean gaudet
2007-12-29  3:31           ` Jan Engelhardt
2007-12-29  6:02             ` dean gaudet
2007-12-29  6:48               ` Jan Engelhardt
2007-12-29  8:29           ` David Newall [this message]
2007-12-29 16:18             ` dean gaudet
2007-12-29 20:35               ` David Newall
2007-12-29 20:40                 ` dean gaudet
2007-12-30  3:43                   ` Valdis.Kletnieks
2007-12-30  3:55                     ` dean gaudet
2007-12-27  3:43 ` Rogelio M. Serrano Jr.
     [not found] <9BTqk-2ck-31@gated-at.bofh.it>
     [not found] ` <9BTJN-2Sv-21@gated-at.bofh.it>
     [not found]   ` <9BTTr-35L-13@gated-at.bofh.it>
2007-12-19 13:43     ` Bodo Eggert
2007-12-19 14:23       ` Al Viro
2007-12-19 15:42         ` Johannes Weiner
2007-12-19 16:44         ` Mark Lord
2007-12-20 20:55         ` Bodo Eggert
  -- strict thread matches above, loose matches on Subject: below --
2007-12-20  1:33 linux
2007-12-20  2:06 ` Mark Lord

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47760578.2090305@davidnewall.com \
    --to=david@davidnewall.com \
    --cc=akpm@linux-foundation.org \
    --cc=dean@arctic.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkml@rtr.ca \
    --cc=viro@ftp.linux.org.uk \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).