Why not sfs load-on-the-fly

Peebee asked why I don't include shinobar's SFS load on-the-fly PET:
http://murga-linux.com/puppy/viewtopic.php?t=76961&start=90

Over the years I have learned to be very wary of modifying the Aufs or Unionfs layers "on-the-fly". It often just doesn't work right.

Anyway, I decided to give it a go. Running Precise Puppy alpha3. I got 'sfs_load' out of shinobar's PET 1.9.4, and placed it at /usr/sbin.

I modified /usr/sbin/filement to recognise if sfs_load exists, and to offer the choice of mounting a file for viewing (prior behaviour), or loading it with sfs_load.

Choosing the latter, it loads ok, as bottom layer, and reports success. However, the files on the bottom layer are not visible "on top". the remount worked to append the layer, but did not update the filesystem.

Was I amiss in only installing /usr/sbin/sfs_load?
Note, my /etc/rc.d/BOOTCONFIG already had the EXTRASFSLIST variable with a "devx" SFS file in it, and sfs_load inserted the new SFS file correctly.

The files on the bottom layer will become visible after a reboot, but that defeats the purpose.


Posted on 25 May 2012, 22:10


Comments:

Posted on 25 May 2012, 22:21 by 01micko
yes!
"Was I amiss in only installing /usr/sbin/sfs_load?"

It runs a service!

I have included it in Slacko since inception with minimal issues, even when I dabbled with unionfs.

Porteus (the aufs distro based on Slackware, relatively small too, fork of Slax) totally rely on loading their "modules" on the fly, that is their packaging system, no other.

:)


Posted on 25 May 2012, 23:01 by Terryphi
SFS load OK
I have tested shinobar's SFS load on-the-fly on Precise, Racy and Wary without problems.


Posted on 26 May 2012, 6:24 by maxerro
SFSandwich
Here's a little treat for recent Aufs-Puppies:
#!/bin/ash

p="/initrd/sfse"
for i; do
case "$(busybox readlink -f "$i")" in
/mnt/*.sfs|/mnt/*.SFS)
busybox mkdir "$p${i##*/}" 2>/dev/null
if [ $? -eq 0 ]; then
busybox mount -t squashfs "$i" "$p${i##*/}" 2>/dev/null && busybox mount -o remount,append:"$p${i##*/}" / 2>/dev/null && echo " +${i##*/}" && menu="yes"
else
busybox mount -o remount,del:"$p${i##*/}" / 2>/dev/null
busybox umount -d "$p${i##*/}" 2>/dev/null && echo " -${i##*/}" && menu="yes"
fi
busybox rmdir "$p${i##*/}" 2>/dev/null &
;;
esac
done
[ "$menu" ] && fixmenus 2>/dev/null && jwm -reload >/dev/null 2>&1

Users in RAM mode probably don't mind (most) SFSs being "above" the base-SFS for that session.
I'm guessing there has been a discussion on what would happen if SFS-extensions were between the base and the rw layer ALL the time?



Posted on 27 May 2012, 10:10 by BarryK
Testing sfs_load
OK, I installed the entire PET, then rebooted. Yep, now it works.

I will accept this, but I like to know what is going on. I had a quick look through /usr/sbin/sfs_load and I don't see why just running it once as I did before, doesn't work properly. I will have to ask shinobar to explain what special thing is done when it is run via /etc/init.d.

I have placed the PET into the 'noarch' repo (31KB):
http://distro.ibiblio.org/quirky/pet_packages-noarch/sfs_load-1.9.5.pet

Note, as I mentioned before, /usr/sbin/filemnt, which runs when left-click on a .sfs file, now detects if sfs_load present and offers the choice of mount .sfs or load with sfs_load.

I did find what seemed like a problem. After using sfs_load, I then ran BootManager and unloaded the .sfs -- which does of course only take affect at next bootup, and after rebooting I saw that /etc/rc.d/BOOTCONFIG.save still had the .sfs in it's EXTRASFSLIST variable.
I fixed this in /usr/sbin/bootmanager (see Woof commit) but I think that is the wrong place to be doing it -- correcting BOOTCONFIG.save should be done by /etc/initd.d/sfs_load.

I have now included sfs_load in the Precise Puppy package list.

Woof commit:
http://bkhome.org/fossil/woof2.cgi/info/2a7963fd95



Posted on 28 May 2012, 8:29 by shinobar
Some answer and issue
Three for answer and the 4th another issue.
1. /usr/sbin/sfs_load works by itself. The problem is always how to manage whiteouts.
2. /etc/rc.d/sfs_load supports additional features, mainly for auto-loading excess sfs over 6 what the initrd did not load.
3. Forget /etc/rc.d/BOOTCONFIG.save. It does nothing at usual operation. It is experimental and acts when you remaster puppy with the file /etc/rc.d/BOOTCONFIG.save. Anyway you may need to edit the BOOTCONFIG.save manually at the remaster.
4. One problem of mismatching sfs_load and woof is the initrd loads sfs in different order from the EXTRASFSLIST. So the rc.update re-works at the next boot. And it becomes more complex when you load sfs over 6. The modified initrd in the Japanese editions load the sfs along with the order of the EXTRASFSLIST.