> unionfs-fuse ... yes it is exist in Debian (as backport). > Why two separate "-o" option group? one goes to unionfs-fuse and the other to FUSE itself.
> The branch(?) is "/tmp/var"=RW:"/var"=RO "/var" mean that /tmp/var (which > is created at /tmp which is a tmpfs - ramdisk) as writable and it is > branch over /var which is read only. My interpretation is correct? Yes, it is. >> I haven't figured out a way to do it using AuFS without moving /var, > What is that mean? Moving /var, basically possible only after mount root > file system, which includes it. Suggestion about unionfs (I have got from > hup.hu) is working if I copy some part of /var to place for rw area for > /var. The translation: > You should make a script which is should run first at the start > (rcS.d/S00unionfs), and it should do the next: > > - create a ramdisk > > mount -nt tmpfs tmpfs /mnt/tmpfs > > - copy/create appropriate directories: > > tar -xzf /etc/unionfs/var.tar.gz > > - and create a union mount: > > mount -t unionfs unionfs /var -o dirs=/mnt/tmpfs:/var > > Many places I have read that aufs could do the same things. It is not true > for my situation? > > Sincerely > tovis AuFS cannot union mount its own mountpoint, so I don't think it's possible. At least I couldn't get such setups to work. The only way to make it work is to copy all the files from /var to /var.real and perform the union mount early in the boot process before anything is written to /var, like this: rm -rf /var mkdir /var mount -t aufs aufs "/var" -o dirs="/tmp/var"=rw:"/var.real"=ro ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d
