why not SFS_load to mount on the fly in EasyOS ?

[Caramel]

Puppy linux and Fatdog have a tool to mount a SFS file without rebooting. It's not possible in EasyOS. Why ?

Is it the lockdown-ram? there is probably the same option in the others OS.
Is it the optional encryption of the partition?
Is it a different layered structure? But the structure for Fatdog (http://distro.ibiblio.org/fatdog/web/fa ... ystem.html) seems very close to that of Easy

If the existence of a file in 2 different layers is a problem, why not have a limited "SFS_load", only for SFSs totally external of easy.sfs (that's to say without common file)?
It could be useful for big applications that would not take up space in snapshots

[BarryK]

It could be done, as EasyOS is using aufs, same as most pups.

Originally, I was planning that would probably move to overlayfs, for which it is not possible, or rather very difficult, to load SFSs one the fly.

However, overlayfs is still flakey in tests I did recently, in fact it doesn't work at all. So staying with aufs.

So could do on the fly loading, except that Easy does an incredible amount of checking of the correctness of the layers at bootup in the initrd. That requires a reboot to do.

So I probably won't implement load on the fly. It is just a minor inconvenience to reboot. It isn't something that you have to do very often.

One exception is that SFSs can be loaded in a container without rebooting.

[rockedge]

@BarryK have you attempted to adapt the SFS-Load from Kennel Linux to EasyOS?

In KLV-Airedale there is a version developed by @fredx181 that works really well in the overlayfs environment. This utility uses symlinks to load a SFS into the system on the fly. Included is a script routine to clean up any dangling links if the system is shutdown or rebooted with a SFS still loaded into the file system and not unloaded beforehand.

If you are interested I could try to test the KLV version in EasyOS. If it works it might be a simple procedure to add SFS-Load to the EasyOS lineup.

[dimkr]

@BarryK This is the overlay implementation of sfs_load in woof-CE: https://github.com/puppylinux-woof-CE/w ... ad.overlay.

"Dynamic loading" is implemented in a one-liner that creates symlinks to the SFS files in a tmpfs layer (https://github.com/puppylinux-woof-CE/w ... verlay#L63) and save2flash (which invokes snapmergepuppy.overlay) ignores these symlinks when saving to disk (https://github.com/puppylinux-woof-CE/w ... 0C2-L180C2).

(I believe the other implementations do the same, or something very similar)

[rockedge]

I have manually installed the SFS_Load xbps package into EasyOS and the first try with the Blender SFS seems to work! Loaded the SFS, started it then deactivated it.

I have not yet integrated the run and finish scripts into the EO boot system.

Results show promise. Whether or not this actually useful will be seen!

[wiak]

"Dynamic loading" is implemented in a one-liner that creates symlinks to the SFS files in a tmpfs layer

Hahaha, one liner? Or just meaning the cp -asn that tinycorelinux uses big-time in its sfs load approach I suppose, which is the obvious symlink creation part only. The complexity is the algorithm to handle side effects such that I myself don't trust this methodology whatsoever. Need to build a list of files/dirs in the mounted sfs, as fredx181 said long time back to be able to get rid of any left behind, and lots more potential complexity involved: making sure mime handling works for new additions, new modules depmod in, whatever the sfs load might introduce. Lots of post-processing in other words, including making sure will work no matter what window manager being used - not a one liner surely???, but I guess that was a joke.

Nah, better like fredx181 later agreed/suggested: create a new overlay (or via fuse in his implementation) and chroot into that. Doesn't integrate so smoothly but allows mounting and running apps in the sfs (loaded on the fly) with much less risk, side-effects, or overhead. Nevertheless, it is a fun experiment, and I've been trying fredx181 implementation too, and it works in my limited-case testing; still don't trust it though.

Also, yeah, save2flash ignoring the links when saving, but then again, what if... same symlink was erased and then created manually and we want save2flash to save it. Like I said, so many potential side-effects to consider. Just loading the sfs via symlinks is itself simple right enough, but only in a naively basic sort of way; such is computing.

[dimkr]

making sure mime handling works for new additions, new modules depmod in, whatever the sfs load might introduce. Lots of post-processing in other words, including making sure will work no matter what window manager being used - not a one liner surely???, but I guess that was a joke.

Nope, not a joke. We have this code in the aufs implementation, it's been reliable for many years and the overlay implementation reuses this old code instead of rewriting it for no reason. Therefore, the overlay implementation of sfs_load in woof-CE really doesn't add much code, it's mostly the creation and deletion of symlinks, then the aufs code path.