Unionfs letting us down?

I used Unionfs in the kernels in Wary and Racy 5.2.2, and I thought that all was well.

However, Forum member vicmz reported a mysterious problem with the desktop drive icons. For example, with 'sda1' icon, click on it and sometimes an error message came up that /root/.pup_event/drive_sda1/AppRun is missing.

It took me several hours, but I eventually traced the original cause of the problem. /sbin/clean_desk_icons runs this line:

rm -rf /root/.pup_event/drive_* 2>/dev/null

However, a test line inserted immediately after;

ls -1 /root/.pup_event

...sometimes, lists the drive_* folders as still present. They are still present later, in the /sbin/pup_event_frontend_d script, and their presence, when they shouldn't be there, upsets the script very much.

Most of the time those folders do get deleted, just sometimes they do not. This is a gross failure, and the only thing that I can think of is Unionfs.

I am running Wary, with 2.6.32.55 uniprocessor kernel, booting off a USB stick. Vicmz has also reported the problem with Racy. I think that vicmz is also using a USB stick for the savefile.

I have been using Wary and Racy for many months without any problems, but most of that time it has been a frugal installation on hard drive.
The USB case would have the top layer of Unionfs in RAM, I don't know why that would make any difference.

Anyway, tonight I will recompile the kernels with Aufs.

---

Comments

Compatibility of sfs


unionfs problems
Username: yoshi314
"i haven't been able to use unionfs with rw tmpfs branch+sqfs ro branch at least since the time unionfs was integrated into the kernel. attempts to access the union mount with tmpfs branch cause lockups or other problemsm, at least for me. that's why i have been using aufs since.

re: sfs-compatibility
Username: maxerro
"Raffy, was that about on-the-fly scripts? The maintainer of the script can include that feature/info if he/she wants to. And about aufs... We have been spoiled by on-the-fly sfs-loading during the past year, which isn't a bad thing since infrastructure is already there and it seems like the logical next step. Precise is the first unionfs-puppy that could pull-off 24/7 load on extremely problematic chipsets from the 2001-2004 era (beats ex-champ-s530 actually), but effortlessness of sfs-manipulation is what makes me drive back to aufs-traffic.

The Unionfs bug
Username: BarryK
"Ok, I have had a rest. My head was hurting, so gave it away. But not before tracking down the cause of the problem a bit closer to it's source... This is what sometimes goes wrong. I have figured out a specific sequence of actions to reproduce this: [code]# rm -rf /root/.pup_event/drive_* rm: cannot remove directory `/root/.pup_event/drive_sda': Directory not empty rm: cannot remove directory `/root/.pup_event/drive_sda1': Directory not empty rm: cannot remove directory `/root/.pup_event/drive_sda10': Directory not empty rm: cannot remove directory `/root/.pup_event/drive_sda2': Directory not empty rm: cannot remove directory `/root/.pup_event/drive_sda3': Directory not empty rm: cannot remove directory `/root/.pup_event/drive_sda5': Directory not empty rm: cannot remove directory `/root/.pup_event/drive_sda7': Directory not empty rm: cannot remove directory `/root/.pup_event/drive_sda8': Directory not empty rm: cannot remove directory `/root/.pup_event/drive_sda9': Directory not empty rm: cannot remove directory `/root/.pup_event/drive_sdb': Directory not empty rm: cannot remove directory `/root/.pup_event/drive_sdb1': Directory not empty rm: cannot remove directory `/root/.pup_event/drive_sr1': Directory not empty [/code] Looking at just one of those directories: [code]# rm -rf /root/.pup_event/drive_sda10 rm: cannot remove directory `/root/.pup_event/drive_sda10': Directory not empty # # ls -a /root/.pup_event/drive_sda10 . ..[/code] However, if I go into the top Unionfs layer: [i]/initrd/pup_rw//root/.pup_event/drive_sda10[/i] there is a whiteout file: [i].wh.__dir_opaque[/i] ...this accursed file hides the files on lower layers. /initrd/pup_ro1, the next-layer-down (the actual save-file) has files in it, which get exposed when files are deleted at the top pup_rw layer. The end result of the above horrible situation is that 'rm' operation fails.

Unionfs bug part2
Username: BarryK
" just by removing that whiteout file, 'rm' succeeds. I have not figured out a definitive solution for this situation, other than a whole lot of checking of the 'opaque' whiteout file on the layers at bootup, which would slow bootup. Unionfs has been criticised for years for excessive use of that 'opaque' whiteout file. I recall, they are following a standard defined for layered filesystems, whereas Aufs sensibly only creates the 'opaque' file when it is really needed. This is a wonderful example of where that 'opaque' whiteout file causes a disaster. So, back to Aufs, again...

/root
Username: L18L
"A chance to change [b]/root[/b] to [b]$HOME[/b] ?

edit-sfs racy problem
Username: ozsouth
"This would explain why, when I use edit-sfs in ram running Racy from a usb stick, the newly-created sfs file is not written to tmp/(a dir name), as happens with other puppies. (I have 2Gb ram in the netbook). Every step works except the final write.

edit-sfs?
Username: BarryK
"Is that a PET package? If so, it is up to the author of the package to make it compatible with the different SFS formats. Wary and Racy have squashfs utilities (squashfs-tools-3.3 and squashfs-tools4-4.2) for both Squashfs v3 and v4. See /usr/sbin/filemnt for example code to detect what type of SFS.

Unionfs / edit-sfs
Username: ozsouth
"The edit-sfs.pet is v3 & v4 compatible (see link below), so I'm suggesting Unionfs is the problem, not Racy itself. Anyway, 'aufs' sounds more like a puppy thing. ;-) http://www.murga-linux.com/puppy/viewtopic.php?t=47469

Tags: wary