All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.