Re: [vserver] readonly root

From: Michael S. Zick <mszick_at_morethan.org>
Date: Thu 10 Mar 2011 - 14:24:09 GMT
Message-Id: <201103100824.13283.mszick@morethan.org>

On Thu March 10 2011, Herbert Poetzl wrote:
> On Thu, Mar 10, 2011 at 07:31:16AM -0600, Michael S. Zick wrote:
> > On Thu March 10 2011, Corin Langosch wrote:
> > > On 09.03.2011 15:10, Martin wrote:
> > > > You may wish to read the Linux Filesystem Standard which tells you which
> > > > part of the filesystem need to be read / write, which can be read only,
> > > > etc. Beyond that you may wish to look at the overlay setup that live
> > > > CDs use.
> > >
> > > When trying to start a vserver from a read-only path it won't work.
> > > chroot-sh complains that several files are read-only, especially
> > > /etc/mtab. I'm now using "aufs" with mounting my "shared root" ro and an
> > > additional very small tmpfs partition rw (so the vserver can be started).
> > >
> > > > Have you looked at vashify / hardlinks?
> > >
> > > Yes, but I think it's not the best for my needs. I may be I wrong, so
> > > I'll explain my needs below. :)
> > >
> > > > Over all what problem are you trying to solve? Read only filesystems
> > > > may not be the best way of acheiving reduced memory / disk usage, etc.
> > >
> > > I need to setup a shared hosting environment where users can also login
> > > using ssh, for example to work with the shell/ installed tools. So my
> > > idea was to have a shared root layout with all common stuff installed
> > > there. It must be read-only, so the users dont alter it. The user data/
> > > application code is in a separate folder and will be mounted inside the
> > > vserver instance as needed.
> > >
> > > Using this layout I hope to achive maximum performance (shared memory,
> > > little virtualization overhead, ..), highest security and still giving
> > > the users the freedom to use the shell/ tools. Now with "aufs", I'm only
> > > worried if it's killing my reduced memory requirements.
>
> > The auFS layer does require its own memory resources, so it will
> > increase your memory usage.
>
> > And here JRO should stop reading (the following is an
> > over-simplification). . . .
>
> > In general, auFS just maps auFS:iNode to the filesystem:iNode used by
> > the corresponding filesystem of multiple filesystems.
> > It does not copy the cached iNode buffer (unless it is creating a
> > new file in the case of the file being written to).
>
> > So I don't think that adding the auFS layer will have broken your
> > overall plan of having everyone reading the same cached iNode.
>
> you are aware that caching and page mapping is based on
> the inode, so as soon as a 'file' shows a different dev:ino
> number it will get a separate chache and of course separate
> mappings, and I really doubt that aufs is designed in such
> a way that it will retain the dev:ino number for those files
>
> but please prove me wrong and check with 'stat' either on
> two separate aufs mounts based on the same source or between
> one mount and the source itself ... stat will show a line
> like this:
>
> Device: 801h/2049d Inode: 479774
>
> if that line differs between those mounts, you have already
> lost in regard of caching and page mapping ...
>

The OP has posed the same question to JRO on the auFS list.
We can follow JRO's reply there.

> note that aufs wasn't designed for improved caching AFAIK :)
>

True.

Mike
> best,
> Herbert
>
> > You may want to setup a more specific layered file system -
> > something with a bit finer distinction than just "root" (/).
>
> > For instance:
> > Put everything that will be RO in the fs tree into a real, read-only
> > (RR) file system (such as squashfs), and;
>
> > Put an auFS layer over just those files of the fs tree that you need
> > to allow system writes to (your example given was /etc/mtab). Although
> > in the case of /etc/mtab you should probably be using /proc/mounts.
>
> > Mike
> > > Thanks,
> > > Corin
> > >
> > >
> >
>
>
Received on Thu Mar 10 14:24:36 2011

[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Thu 10 Mar 2011 - 14:24:36 GMT by hypermail 2.1.8