Cause of Unionfs/Aufs failure

Over the years I have played with both of these. Originally Puppy used Unionfs, then I went over to Aufs, then back to Unionfs.

The reason that I went back to Unionfs is I had a situation where Aufs refused to create the layers, whereas Unionfs did and worked. Well, I conducted some experiments today and perhaps it is just luck the Unionfs worked under that situation, or maybe the older version worked.

A configuration that Aufs refuses to deal with is when I had a frugal install to the Classmate and chose the "pup_save" to be the entire partition. Puppy will then boot in PUMODE 6 or 7, the latter looking like this:

tmpfs top layer
sda1 "pup_save" is entire partition
pup_404.sfs mounted by loop device

These are the layers. This worked okay before, but now Unionfs crashes and Aufs is intelligent enough to detect a conflict. The reason it worked before Puppy 4.1alpha4 is that the default was to copy the pup_404.sfs to RAM first -- well, it was only copied if there was enough RAM.

The situation now is that the default is it is not copied. The 'pup_404.sfs' is located in /dev/sda1, and that is the conflict. Aufs sees that the same file is in two layers, Unionfs dumbly goes ahead but then may or may not crash.

Perhaps Unionfs and Aufs could be made to handle this situation, but anyway what I have done is put in a fix that forces 'pup_404.sfs' to be copied to RAM if PUPMODE is 6 or 7. This will happen regardless of the amount of RAM.

Posted on 15 Jul 2008, 19:14


No comments posted yet.