From: Emmanuel Colbus <ecolbus@manux.info>
To: "Theodore Ts'o" <tytso@mit.edu>, linux-kernel@vger.kernel.org
Subject: Re: [RFC][6/11][MANUX] Kernel compatibility : directory hardlinks
Date: Wed, 16 Apr 2014 04:14:33 +0200 [thread overview]
Message-ID: <534DE789.8000104@manux.info> (raw)
In-Reply-To: <20140415233435.GS4456@thunk.org>
Le 16/04/2014 01:34, Theodore Ts'o a écrit :
> On Wed, Apr 16, 2014 at 01:12:53AM +0200, Emmanuel Colbus wrote:
>> The solution is to use directory hardlinks. This way :
>> - applications that want to communicate through /tmp can simply specify
>> that they have a dependancy on a package that provides a /tmp directory
>> for them; this way, the package manager will create a directory hardlink
>> named "/tmp" towards it in their chroot, and they will be able to do
>> their thing;
>> - as for the cleaning of /tmp, it is done by having all the /tmp
>> directories of all the applications hardlinked within the chroot of the
>> script tasked with cleaning them.
>
>
> That's what "bind mounts" in Linux are used for.
>
> If you haven't studied how bind mounts and mount namespaces work in
> Linux, I'd strongly encourage that you take a look. First of all,
> it's a much more powerful system, and secondly, that's what most
> container based systems are using.
Yes, I know about bind mounts; in fact, I've even used them as a Linux
sysadmin, and I thought about using them here. My issues with them
were :
- bind mounts are not persistant (they have to be re-instated at every
boot);
- I would have needed plenty of them (if a computer had 10.000
applications that each used a /tmp directory, then this would have
required 10.000 bind mounts),
- the initialization of the operating system would have been impossible.
Who would have created the bind mounts required for the proper operation
of init?
- As an annoying note, the creation of the bind mounts would have
required giving mount an access to, de facto, any directory in the system;
- More problematically, giving the mount process this access would have
required either to install mount, and all its dependancies, unchrooted
and completely outside of the whole architecture, or using something to
give mount this access from within its chroot. The annoying thing being
that this "something" needed would have been, uh, a bind mount.
- and finally, unless I'm mistaken, bind mount do not stack. That is, if
you have three groups of directories, a, b, and c, and you bind mount c
into b/c and b into a/b, you won't be able to access c as a/b/c. Thus,
the amount of bind mounts required to do this would have been clearly
astronomic. (1)
In addition, I had already determined that, to do what I wanted to do, I
would need a new kind of partition (for the rootlinks). So I decided I
could also go with directory hardlinks.
However, I *did* recognize that bind mount were very close to what I
needed. That's why I created my directory hardlinks in this way, as, in
fact, "static" bind mounts.
Regards,
Emmanuel
(1) By the way, don't worry, I didn't forget to put a security
preventing circular mounts, even with intermediary steps :-)
prev parent reply other threads:[~2014-04-16 2:14 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-15 13:43 [RFC][6/11][MANUX] Kernel compatibility : directory hardlinks Emmanuel Colbus
2014-04-15 20:06 ` Theodore Ts'o
2014-04-15 20:53 ` Emmanuel Colbus
2014-04-15 22:01 ` Theodore Ts'o
2014-04-15 23:12 ` Emmanuel Colbus
2014-04-15 23:34 ` Theodore Ts'o
2014-04-16 2:14 ` Emmanuel Colbus [this message]
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=534DE789.8000104@manux.info \
--to=ecolbus@manux.info \
--cc=linux-kernel@vger.kernel.org \
--cc=tytso@mit.edu \
/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