kernel, Unionfs

I have compiled this kernel and intend to use it for Quirky 010. However, I am still treating it as temporary, as some major bugs were fixed relative to 2.6.33 -- perhaps things will have settled down by

The worm has turned, we are back onto using Unionfs rather than Aufs. I did this after Jemimah reported that Unionfs solved problems with f.s. corruption. This is version 2.5.4 of Unionfs.

Unionfs has some advantages, such as better handling of writing directly to a lower layer (branch) -- a feature that we make use of when installing PET packages -- see variable 'DIRECTSAVEPATH' in /usr/local/petget/installpkg.sh.

Unionfs also used to have an advantage, I was able to mount extra SFS files when the "pupsave" is a complete partition rather than a file -- but it has been a long time since I looked into that.

I have uploaded the patched source, etc., to here:

Posted on 18 Mar 2010, 9:57


Posted on 18 Mar 2010, 11:28 by Jemimah
updating layerfs bug in init script
There's a slight issue in the init script that's cropped up since I switched to unionfs. In pupmode 12 sometimes it will update the layered filesystem with every boot.

I'm not entirely certain I've figured it out totally, and I don't think I'm using your most recent init script, but here's what I did to fix it

#update /etc/rc.d/BOOTCONFIG with latest unionfs layers configuration...
mv /pup_rw/etc/rc.d/BOOTCONFIGNEW /pup_rw/etc/rc.d/BOOTCONFIG

It doesn't appear to be unionfs related. It looks like the script cats the file into itself, which must work most of the time, but not always.

Dunno, let me know if I'm missing something.

Posted on 18 Mar 2010, 11:44 by kirk

I've been kind of on a parallel path. I've been building a 64bit puplet. I'm on 2.6.33 right now, haven't had any problems with the pup_save, that's using AUFS2. I do everything with a frugal install as well. I'm going to build soon too, this time with NFS support for AUFS. There is a config option for direct writing to the branches too, though I've never tried it because the docs say it has some overhead associated with it. Still to scared of Unionfs.

Posted on 18 Mar 2010, 12:37 by Jemimah
Hi Kirk,
If you do an fsck after shutting down, does it come back clean? No orphaned inodes? This may not be immediately apparent until the error messages start flashing by during startup. Maybe something in your kernel configuration avoids this bug...

Are you using the ext4 driver for ext2 and ext3? It's pretty nice because then you can have any ext filesystem inside the save file, and the init script will just work without extra logic.

Posted on 18 Mar 2010, 15:07 by BarryK
Sync problem
That sync problem was fixed on February 22, 2010 in Woof.

Posted on 18 Mar 2010, 15:33 by BarryK
Writing to branches
Yes, Aufs has a mode by which inotify is used to monitor all the files on the layers, but it has a considerable performance hit.

Unionfs has a mechanism to notice a direct write to a layer and to adjust the "top view" accordingly, as does Aufs (in it's normal mode that we use with Puppy), however it isn't perfect with either -- writing a complete PET package direct to a layer, some parts of it are not visible on top (until after a reboot).

However, what Unionfs has, that as far as I'm aware Aufs doesn't, is the ability to manually force a flushing of the cache and re-evaluation of the layers. It is done by a remount, like this:

mount -t unionfs -o remount,incgen unionfs /

...this is a complete re-evaluation and works perfectly. See my /usr/local/petget/installpkg.sh.

I did actually try and explain this on the Aufs mail list once, but perhaps they never understood what I was asking for, or didn't appreciate the value of it.

Posted on 18 Mar 2010, 22:03 by kirk

Having orphaned inodes on a pup_save has been a problem since Puppy 2, with Unionfs or Aufs. That problem stems from not being able to cleanly unmount everthing after switch rooting from the initrd to the main sfs. Does the latest Unionfs manage to fix that? If so I might give Unionfs another try. If you're using a journaled file system inside your save file, as soon as you mount it, the journale is recovered and the filesystem is repaired.

Didn't know that about ext4, might try that out. At one time I did run ext3 inside my save file, but if the save file was on NTFS, you would get some errors at shutdown, don't remember what they where.

Posted on 18 Mar 2010, 22:45 by kirk
Writing to branches
Thanks for the info Barry. I do remember now, that's for a usb flash drive install.

Posted on 19 Mar 2010, 4:10 by Jemimah

With unionfs and ext4 (with journal) the fsck comes back squeaky clean except superblock timestamp. I need to go back and test with ext2.

With Aufs, and ext4, there were always at least 6 or 7 orphaned inodes, despite journal recovery. Also the new driver will occasionally make announcements about this to the user during boot, which makes people understandably concerned about it.

If you try unionfs, you'll want this patch, otherwise many browsers and other applications will crash.

Also, I had to mount some tmpfs on /dev/shm to prevent Chrome from crashing the kernel. This likely effects any program that uses shm, so I'd recommend adding that to your sysinit script.

Posted on 19 Mar 2010, 4:20 by Jemimah
Nevermind, I just force checked my save file and there was one messed up inode - but one is better than a bunch, and there have been no complaints during boot since I switched.

An interesting experiment in any case.

Posted on 19 Mar 2010, 9:13 by BarryK
Unionfs patch
Oh, I didn't apply that patch. I'm running with the kernel now with unpatched Unionfs, stable so far.

Anyway, I do plan to move up to or later.

Ok, I modified rc.sysinit in Woof to always load tmpfs on /dev/shm

Posted on 19 Mar 2010, 12:45 by Jemimah
Chrome definitely triggers the setattr/unlink bug, and Firefox did when I was playing with unionfs last year. But seamonkey didn't trigger it. Rumor has it that wine and kde crash as well.

Posted on 21 Mar 2010, 10:33 by BarryK
Unionfs works if save to entire partition
I reported above that Unionfs has two very important advantages over Aufs. One of those is that we can mount a SFS file as one layer, even though the file is resident in a lower layer -- Aufs refuses to do this.

However, it has been a long time since I tested this. So, I installed Quirky 010 to a Flash stick which has a ext3 f.s. and on first shutdown chose to save to the entire partition.

I also placed an OpenOffice SFS file in the Flash stick. After rebooting, I chose to load the SFS file in the BootManager, rebooted -- and it works!

OpenOffice itself crashes the system -- but that's a different problem. As Jemimah reported, a patch is required for Unionfs to prevent that -- hopefully.

But, I was able to cruise around in the OpenOffice directories and open files, Unionfs was happy.

This is very good news, a major reason why we should stay with Unionfs if at all possible.