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.


Posted on 2 Apr 2012, 12:51


Comments:

Posted on 2 Apr 2012, 13:12 by Raffy
Compatibility of sfs
Another issue that needs mentioning is compatibility of sfs. Add-on sfs tend to be useful across Puppy versions (like OpenOffice sfs4 beginning with Puppy 4.3.1), so perhaps a script can tell if it's no longer fully compatible with a new Puppy?


Posted on 2 Apr 2012, 15:07 by yoshi314
unionfs problems
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.


Posted on 2 Apr 2012, 15:49 by maxerro
re: sfs-compatibility
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.



Posted on 2 Apr 2012, 16:28 by BarryK
The Unionfs bug
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:

# 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


Looking at just one of those directories:

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


However, if I go into the top Unionfs layer:

/initrd/pup_rw//root/.pup_event/drive_sda10

there is a whiteout file:

.wh.__dir_opaque

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



Posted on 2 Apr 2012, 16:31 by BarryK
Unionfs bug part2

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



Posted on 2 Apr 2012, 16:47 by L18L
/root
A chance to change /root to $HOME ?




Posted on 3 Apr 2012, 8:49 by ozsouth
edit-sfs racy problem
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.


Posted on 3 Apr 2012, 9:31 by BarryK
edit-sfs?
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.



Posted on 3 Apr 2012, 15:35 by ozsouth
Unionfs / edit-sfs
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