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.

Tags: puppy