overlayfs and sfs load/unload

[fatdoguser]

Using fatdog as a build and template system I compiled the latest 6.6.9 kernel from kernel.org, so no aufs (or patches).

Directly mounting the devx.sfs and then inserting that mount point as a middle layer in a overlayfs, followed by a chroot to / ... and I could run gcc. Exit the chroot and the loading of the devx.sfs disappears (gcc no longer available).

I did set the overlayfs to record changes in a folder that I remove as part of the exit of chroot (unload of sfs) clean-up, but if instead the folder is left you have a record of what changes were made whilst the sfs was loaded, so for instance any changes under /home that occurred whilst the sfs was loaded could be applied to the main systems /home (selective changes such as creating new files whilst the sfs was loaded being preserved rather than lost after the sfs was unloaded).

In a limited sense it would seem that dynamically loading/unloading sfs's under a overlayfs is relatively trivial. For more complex combinations however and its less viable. Singular (or multiple sfs's being) loaded at the same time, unloaded together would be fine. Loading/unloading sfs's in a more random manner would be much more awkward to manage/code, if not impossible.

[jamesbond]

I have been thinking along the same way (but with different implementations).

It is already possible to use this in standard Fatdog, by loading the SFS, and then run sandbox.sh (or rw-sandbox.sh if you want to have persistence); and when done, leave the sandbox and unload the SFS. In fact, for my own use, I'm associating .img files and folders with Rox right-click to launch rw-sandbox.sh; and it works very well. But currently both sandboxes require that the SFS is pre-loaded. I might extend the scripts to enable (temporary) loading of SFSes which used only for the lifetime of the sandbox.

This seems to be the cleanest way to load/unload SFS, and is probably the way I would take once aufs time is up. The ability to load SFS at the rootfs level is a very nice convenience, but that's not its primary purpose. The primary purpose is to be able to use the software in the SFS without having to reboot, and this way definitely does it. The isolation is the cherry on top, and as you said, we can fortify it by dropping capabilities.

[fatdoguser]

@jamesbond sfs -> app-images -> full systems ... and to me the current form is vnc loading/unloading entire desktops or apps within those. Where each might be local (kvm/qemu vm set to serve out vnc, or a overlayfs mounted sfs, chroot into that and start vncserver (or have it set to auto run vncserver), or a cloud based system that serves via vnc).

My present messing-around boot is to (vesa/simpledrm) framebuffer, boots in a second. sym link fd64.sfs and overlayfs mount that, where its set to serve out vnc (vncserver) and that's about ready by the time wifi network connection has completed. fbvnc into that and ... a full X/gui desktop ready to go pretty quickly, all running (viewed) in a generic framebuffer.

I've extended that to then vncviewer into a hard wired box running x0vncserver. When the fps is dropped to 10 and color depth set to 16 bit, that's phenomenal whilst the look-n-feel is still good despite the low frame rate and reduced color depth. 720p full screen youtubes in chrome seeing max throughput of 5MB (40Mbs) rate, more often around 3MB/sec with a video playing, a lot lower for more idle screens. So my old/slow wifi connected laptop has the appearance of running at i5/nvidia hard wired ethernet speeds.

Where you can add (or remove) elements, by just adding in another vnc connection (to your phone/whatever) ... if a particular program is deemed best run/served from that. Whilst potential issues of layering of loads/unloads is pretty much irrelevant.

Distributed processing ... our i5/nvidia/hard wired does the youtube downloading/rendering .. comfortably, along with x0vncserver serving of vnc. Whilst the laptop has to handle vncviewing, along with running a overlayfs mounted Fatdog session that serves out vnc to fbvnc viewer. Yesterday I set that to start vncserver using spot rather than root, and that's working well, in effect X running as spot, along with anything else started within that.

PID USER COMMAND VSZ STAT
1 root init 4340 S
211 root battery-monitor 4340 S
222 root autologin 4340 S
227 root sh 4340 S
311 root wpa_supplicant 9596 S
336 root udhcpc 4340 S
341 root laptop 4340 S
342 root sfsload 4340 S
370 root .v 4340 S
382 spot vncstart 3964 S
391 spot Xvnc 127m S
398 spot jwm 165m S
410 spot xload 5260 S
411 spot fbvnc 4588 S
413 spot urxvt 15m S
414 spot sh 4228 S
415 spot o 7132 S
423 spot chrome 32g S
425 spot chrome_crashpad 32g S
428 spot chrome_crashpad 32g S
433 spot chrome 32g S
434 spot chrome 32g S
460 spot chrome 32g S
468 spot chrome 32g S
560 spot chrome 32g S
1470 spot dbus-launch 4116 S
1471 spot dbus-daemon 3952 S
1473 spot at-spi-bus-laun 295m S
1478 spot dconf-service 150m S
1482 spot dbus-daemon 3952 S
1498 spot at-spi2-registr 152m S
1853 spot chrome 1.1t S
2002 spot chrome 1.1t S

All cpu's and bandwidth involved are comfortable, low to modest. And at 5MB/sec peak type data rates that's within the realm of having a good desktop experience even if out-and-about, maybe just having to settle for watching youtubes at 420p on slower links.

Locally sfs load say Blender, or instead vnc connect to a x0vncserver/vgl based choice that runs Blender within windows/mac/linux/whatever, with the hard-work mostly being done by the remote system. And that you can attach/detach to/from, leave it to render for hours in the background.