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 ...
note that aufs wasn't designed for improved caching AFAIK :)
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:06:38 2011