With this in place, pupmode=66 is more vialable for long-term use.
But it can still run totaly in RAM.
And it will still work on any filesystem.
On shutdown:
Each "save" creates a new savesfs file of the current '/initrd/pup_rw' directory in RAM, so each savesfs contains only changes.
The savesfs filename has the form ${DISTRO_FILE_PREFIX}save66_${date+time}.sfs, e.g. 'upupjj+dsave66_20231206-2211.sfs'.
So after a while there will be a number of these savesfs files in the save location.
On boot:
All the current savesfs files are mounted as a read-only overlay at '/pup_save'.
So the '/' overlay is mounted with "lowerdir=/pup_save:/pup_sfs,upperdir=/pup_rw".
('/pup_sfs' is a read-only overlay of the all the Puppy sfs files.)
(In a running Puppy these directories have '/initrd' prepended to the path.)
By default the savesfs files are copied to RAM if the Puppy sfs files are.
But there are new "pfix=svcopy" and "pfix=nosvcopy" boot parameters to control savesfs copying independently.
For a fast boot from a slow usb stick, I used "pfix=nocopy,svcopy"
combine-save-sfs
This utility combines all the current savesfs files into a single new savesfs file, with a 'c' appended, e.g. 'upupjj+dsave66_20231206-2234c.sfs'.
If the current savesfs files on disk were copied to RAM, the files on disk are deleted.
Otherwise a remove_files.lst file is created so they can be deleted during the next boot.
On successful completion a no-save reboot is performed.
Running "combine-save-sfs --help" does produce a usage message.
How to try:
I have uploaded 'JammyPup32-save66sfs.zip', 'local-initrd.gz', and 'ydrv-save66sfs.sfs' to https://www.mediafire.com/folder/rt7rcavwgqdag/savesfs.
You can put it together yourself, using 'local-initrd.gz', and 'ydrv-save66sfs.sfs' in the Puppy of your choice.
Or, on a uefi booting computer, unzip 'JammyPup32-save66sfs.zip' into an empty bootable usb stick. Then boot the usb stick.
The 'init' script included in the above, does not support any other form of "save", it is just to demonstrate/test this "save" concept.
Whiteout files
In the interest of minimising the IO involved, each savesfs is created by mounting the various elements into a read-only overlay, and then running a mksquashfs of the overlay.
Any whiteout files are interpreted in the reading of the stack, so they are never transfered to the savesfs file as whiteout files.
Appropriate whiteout files are copied to a tar archive, which is included in the savesfs as '/var/saved-whiteouts.tar'.
On boot, this tar file is extracted into the empty '/initrd/pup_rw' directory in RAM.
During 'combine-save-sfs' processing, only those whiteout files that "cover" a file in '/initrd/pup_sfs' are kept.