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.

---

Comments

yes!
Username: 01micko
"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. :)

SFSandwich
Username: maxerro
"Here's a little treat for recent Aufs-Puppies: [code]#!/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[/code] 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?

Testing sfs_load
Username: BarryK
"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

Some answer and issue
Username: shinobar
"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.

Tags: puppy