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 > > > > > > > > > >