site  contact  subhomenews

Managing changed SFS layers at bootup

September 20, 2017 — BarryK

Easy OS, like Puppy, runs on a layered filesystem, with one or more read-only (ro) SFS files in lower layers, and a read-write (rw) layer at the top.

The interactions of the files and folders in these layers can cause trouble. Puppy has some quite complicated code, in the init script in the initrd, and in /etc/rc.d/rc.update, to examine the layers and make sure that nothing "important" underneath is blocked by a higher file/folder or whiteout file.

The decisions made are not perfect though.

Easy 0.4 and earlier do no processing of the layers, they are just layered as-is. That is not satisfactory either.

The layers can change either by adding or removing a SFS file, or at a version upgrade. The rw layer is the .session folder, below will be session.sfs, then maybe extra SFS files such as devx-*.sfs, then q.sfs at the bottom.

File session.sfs is the accumulated sessions from previous versions, compressed and frozen as read-only.

I thought of handling the whiteout files in a radically different way: just delete all of them. That is, delete all of them in the .session folder.

At a version upgrade, this ensures that no whiteout files get frozen into session.sfs, and in a changed SFS layer arrangement, nothing from below will be hidden or renamed.

At first, this might seem too radical. However, all changes in the rw layer will not be undone. For example, you install a DEB package, then later uninstall it. This happens entirely in the rw layer.

Say that you install a package into /opt in the rw layer, then later delete /opt. There will then be a whiteout file hiding any /opt folders in lower layers. By removing the whiteout, the lower /opt will spring back into existence on top. Which is good.

Deleting all the whiteout files in the .session folder is now done in the init script in the initrd, a one-liner:

find /mnt/${WKG_DEV}/${WKG_DIR}.session -type f -name '.wh.*' -delete 2>/dev/null

But, this is only done when the layers change or at a version upgrade.

I know that this seems one step too far, and feedback from other pup developers is welcome. The Easy OS forum thread is here:

Actually, I think this will work OK because only the top layer is rw. In Puppy, where the next-down may also be rw, it gets more complicated.

Following the reasoning presented above, take one more step: why not do away with whiteout files entirely?

Later in the init script, the layered filesystem is setup, using aufs, then there is a switch_root to the working partition, then /etc/rc.d/rc.sysinit will run, which will call rc.update.

Next, I have to put some code into rc.update, to process the changed layers some more. For example, the JWM menu might need to be reconstructed.

Tags: easy