Another re-write of the "init" script - using OverlayFs?

Under development: PCMCIA, wireless, etc.
Message
Author
gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#61 Post by gyro »

Rangan Masti wrote:May be Light House Puppy init could be just an example!!!
Thanks, but on further thought, I've decided not to go this way. It's simple and obvious when setting it up, but there might be some difficulties when trying to remove a live sfs from the running system.
So I've implemented one that uses a list, which unfortunately then needs a utility to maintain that list. But more on that when I get to the point of releasing it.

Note: Many of the things I try, are ideas I've seen in the forum over the years. Many of these have never been incorporated into official puppy. e.g. using sfs files as a save mechanism.

gyro

Rangan Masti
Posts: 37
Joined: Tue 01 Jan 2013, 19:23
Location: Germany, Berlin

#62 Post by Rangan Masti »

Hi, thank you for the reponse. Do not give up!!. Try further. Wish you a good success!!

Rangan

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

Updated version

#63 Post by gyro »

I've uploaded new versions to http://www.fishprogs.software/puppy/initrd/initrd.gz and http://www.fishprogs.software/puppy/ini ... verlay.sfs.
Both need to be downloaded, since the "ydrv_overlay.sfs" now contains a new utility "extra_sfs", and the command line utilities "file2initrd" and "initrd2file".

The significant change in this 18 July version is, extra sfs support.

The "extra_sfs" utility is a replacement for "sfs_load", in the sense that it masks "sfs_load" and takes its place in the menu.
But it does not load or unload any sfs files.
It simply maintains a list of extra sfs files that are loaded by "init" into the "pup_sfss" overlay, before the main overlay is created.

If "init" fails to load any extra sfs file, an appropriate message is written to "/initrd/tmp/bootinit.log", but the file remains in the list.
You can then either use "extra_sfs" to remove the failing entry, or fix the problem so that it will load successfully next boot.

The list is stored as a variable called "XTRA_SFS" in the "BOOT_SPECS" file.
This file can reside in the frugal install directory or in "initrd.gz", but it must reside in the same place as "DISTRO_SPECS".
So if you use the "file2initrd" utility to move "DISTRO_SPECS" into "initrd.gz" then you should do the same with any "BOOT_SPECS".
Also if you move these files into "initrd.gz", it will confuse "extra_sfs" if copies still exist in the frugal install directory. So either delete them, or rename them.
It's easier to just leave these files in the frugal install directory.

Note on DISTRO_SPECS:
This file defines the puppy you are booting, so the same "initrd.gz" can boot many different puppies provided it has access to the appropriate DISTRO_SPECS.
So, having this file outside "initrd.gz" means the same "initrd.gz" file can be tested with many puppies without change, I've booted both 64bit and 32bit puppies with the same "initrd.gz".
The limitation of the current "initrd.gz" is that the puppies kernel must support overlayfs.

gyro

Rangan Masti
Posts: 37
Joined: Tue 01 Jan 2013, 19:23
Location: Germany, Berlin

#64 Post by Rangan Masti »

Hi, good work !
--Testing!!. Have a nice evening.

Rangan

User avatar
peebee
Posts: 4370
Joined: Sun 21 Sep 2008, 12:31
Location: Worcestershire, UK
Contact:

#65 Post by peebee »

Looking good here - although I did have an oddity when I did a reboot - I got the saving message but this was followed by a dropout to the terminal prompt and neither reboot nor poweroff actually worked - had to press the power off button....

Code: Select all

# lsoverlay
/initrd/mnt/tmpfs/pup_rw
/initrd/pup_a
/initrd/pup_y
/initrd/pup_ro2
/initrd/pup_f
/initrd/pup_z
/initrd/pup_5
Attachments
Screenshot.png
(147.39 KiB) Downloaded 281 times
ImageLxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#66 Post by gyro »

peebee wrote:Looking good here - although I did have an oddity when I did a reboot - I got the saving message but this was followed by a dropout to the terminal prompt and neither reboot nor poweroff actually worked - had to press the power off button....
Hmm.., I've never seen "rc.shutdown" dropout to a terminal.
Did you try Ctrl+Alt+Delete?
Does it do it every shutdown?
What pupmode are you running? (see /etc/rc.d/PUPSTATE.)

Edit: Never mind the pupmode question, it looks like you are running in pupmode=21.

gyro

User avatar
peebee
Posts: 4370
Joined: Sun 21 Sep 2008, 12:31
Location: Worcestershire, UK
Contact:

#67 Post by peebee »

gyro wrote:
peebee wrote:Looking good here - although I did have an oddity when I did a reboot - I got the saving message but this was followed by a dropout to the terminal prompt and neither reboot nor poweroff actually worked - had to press the power off button....
Hmm.., I've never seen "rc.shutdown" dropout to a terminal.
Did you try Ctrl+Alt+Delete?
Does it do it every shutdown?
What pupmode are you running? (see /etc/rc.d/PUPSTATE.)

Edit: Never mind the pupmode question, it looks like you are running in pupmode=21.

gyro
Ignore me - it was just an oddity - am unable to replicate/repeat the problem....

One quirk/feature I notice is that the frugal install partition is not mounted after boot which is what you would expect with the aufs initrd.....so for example extra sfs manager does not work until the partition is mounted.....
ImageLxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#68 Post by gyro »

peebee wrote:Ignore me - it was just an oddity - am unable to replicate/repeat the problem....
I also have been unable to replicate.
I just tried it with a fresh frugal install of LxPupSc-17.07.23T.iso.
peebee wrote:One quirk/feature I notice is that the frugal install partition is not mounted after boot which is what you would expect with the aufs initrd.....so for example extra sfs manager does not work until the partition is mounted.....
Pupmode=21 is an extension of pupmode=5, everything is in ram, even extra sfs's. So no partitions are mounted by default in the running system.
"extra_sfs" needs direct access to files in the frugal install directory, so it won't run until the partition is mounted manually, in pupmode=5 and pupmode=21.
Code could be added to "extra_sfs" to mount the partition if required, after all "rc.shutdown" has to do just that so it can write the save sfs. I'll think about it.
I tend to avoid this issue by creating an empty save folder, thus switching to pupmode=12 on the next boot.

gyro

User avatar
peebee
Posts: 4370
Joined: Sun 21 Sep 2008, 12:31
Location: Worcestershire, UK
Contact:

#69 Post by peebee »

gyro wrote:I tend to avoid this issue by creating an empty save folder, thus switching to pupmode=12 on the next boot.

gyro
Ahhhh - hadn't twigged you could / should do that.....

If I do....

what is the ....work directory for?

what is the relationship of the save folder to the ...save.sfs.bak?

Thanks
peebee
ImageLxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#70 Post by gyro »

@peebee,
Before I answer your questions there is just 1 thing:
Adding

Code: Select all

CONFIG_TMPFS_XATTR=y
to your kernel config should improve reliability when tmpfs is used as the rw layer of the main overlay, i.e. pupmode=5,21,29.
I noticed in my recent LxPupSc test that in dmesg, overlayfs complained that the upper fs does not support xattr.
peebee wrote:what is the ....work directory for?
It's required by overlayfs for it's own internal use.
In pupmode=5,21,29 it's there as "/initrd/mnt/tmpfs/pup_wk".
peebee wrote:what is the relationship of the save folder to the ...save.sfs.bak
When "init" finds an empty save folder, it copies the content of ...save.ram.sfs to the save folder and then uses that as the rw layer directly. This provides a seamless transition from pupmode=21 to pupmode=12.
After this all changes are written directly to the save folder. No new ...save.ram.sfs is produced and ...save.ram.sfs.bak is ignored.
So ...save.ram.sfs.bak is the sfs that was used to populate the initialy empty save folder.

gyro

User avatar
peebee
Posts: 4370
Joined: Sun 21 Sep 2008, 12:31
Location: Worcestershire, UK
Contact:

#71 Post by peebee »

gyro wrote:Adding

Code: Select all

CONFIG_TMPFS_XATTR=y
to your kernel config

It's required by overlayfs for it's own internal use.

...save.ram.sfs.bak is ignored.
Thanks....

config changed for next kernel build....

does ....work have to be in the frugal install directory? perhaps it can be in /tmp or deleted at shutdown??

perhaps ....save.sfs.bak can also be deleted when no longer needed?
ImageLxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#72 Post by gyro »

peebee wrote:config changed for next kernel build....
Thanks, I look forward to that.
peebee wrote:does ....work have to be in the frugal install directory? perhaps it can be in /tmp or deleted at shutdown??
According to the overlayfs documentation, it has to be in the same file system as the rw directory.
It seemed like a simple idea to always put it beside the rw directory.
It's required, why should it not be obvious?
peebee wrote:perhaps ....save.sfs.bak can also be deleted when no longer needed?
The ...save.ram.sfs.bak file could be deleted at any time. It's just some backup, it's never actually used.
It's not even necessary to create it. It simply provides an extra recovery option if things go pear-shape. This is still a testing environment.

gyro

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#73 Post by gyro »

peebee wrote:config changed for next kernel build....
I just tried a fresh frugal install of LxPupSc 10.07.25, and it's 4.12.3 kernel seems to have fixed the issue.
gyro

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

A reflection on where it's at

#74 Post by gyro »

So what have we learnt from this project?

Issues:

1. It has been reported on the net that there is a problem with using tmpfs as the upper fs for an overlay.
This is of concern because this init script does this for pupmode=5, pupmode=21 and pupmode=29.
Apparently this problem is related to a lack of extended attribute support in tmpfs, which can be fixed by compiling the kernel with "CONFIG_TMPFS_XATTR=y".
Fortunately the kernels in slacko 6.9.9.9 and LxPupSc 17.07.25 meet this requirement. Unfortunately the released kernel in xenialpup 7.0.8.1 does not.
The issue can be avoided by running in pupmoode=12.
Note: I have never experienced any problem, although I did notice recent kernels did complain with "overlayfs: uppper fs does not support xattr" in dmesg.

2. Compared to aufs, overlayfs has some significant limitations, i.e. can't add or delete directories in a stack, can't directly modify the contents of a directory in a stack.
This init script works within these limitations.

Things we can do:

1. We can boot and run normal woof-ce puppies using overlayfs for the stack.
The upside is, overlayfs is supposed to be very efficient, and is supported directly in the kernel, (no aufs patch needed).
The downside is, "sfs_load" is gone, the stack has to be completely created by init.
We can still have extra sfs's, it's just that it takes a reboot, to actually load or unload an sfs.

2. The same initrd.gz can be used to boot many different puppies.
I introduced the facility for init to use a DISTRO_SPECS from outside the initrd.gz to simplify testing.
But it has demonstrated that, just as we can move huge-kernels from one puppy to another, it's possible to move initrd.gz's from one puppy to another.
So I can take this initrd.gz, push my "TIME_ZONE" file into it, and expect to be able to boot any woof-ce puppy with it, after extracting the puppies DISTRO_SPECS from the release initrd.gz.

3. We can easily specify things like extra sfs's before first boot, using a BOOT_SPECS file, beside the DISTRO_SPECS file.
(And any specified extra sfs's will be loaded by first boot.)

4. We can have a puppy that has automatic persistence, without shutdownconfig.
Of course pupmode=21 has significant limitations, i.e. it all has to fit back into the tmpfs on next boot.
So it would not be recommended for use as a "work" puppy.

Other new things:

1. Enable save folder by simply creating an appropriately named directory.
If done before first boot, e.g. as part of installation, it will be ignored until first reboot.

2. "pfix=nosave" boot parameter, disables automatic saving at shutdown in pupmode=5, pupmode=21 and pupmode=29, i.e. when /initrd/mnt/tmpfs/pup_rw is the rw directory of the main overlay.

3. "pfix=rosave" boot parameter, use a read-only save layer, i.e. choose pupmode=29 instead of pupmode=12.
Pupmode=29 is a replacement for pupmode=13, but I didn't want to confuse puppy utilities like snapmergepuppy.

4. "pfix=nobs" boot parameter, disable processing of BOOT_SPECS file.

5. "pfix=nofsckp" boot parameter, disable fsck of each partition before first mount.
The previous "pfix=fsckp" processing is now the default.

gyro

woodenshoe-wi
Posts: 109
Joined: Sat 29 Jul 2017, 03:16
Location: Wisconsin

RE: A reflection on where it's at

#75 Post by woodenshoe-wi »

I just wanted to let you know that after replacing the 386 binaries in the initrd.gz with ARM binaries I was able to use your init script on my Pi2 (1GB RAM) with only two small modifications.

Code: Select all

--- original_init	2017-07-17 09:25:51.000000000 -0500
+++ edited_init	2017-07-19 13:02:38.000000000 -0500
@@ -574,6 +574,12 @@
 [ -d /mnt/tmpfs ] || mkdir -p /mnt/tmpfs
 mount -t tmpfs tmpfs /mnt/tmpfs
 
+#raspberry pi, load squashfs kernel module
+[ -d /mnt/boot] || mkdir -p /mnt/boot
+mount /dev/mmcblk0p1 /mnt/boot
+insmod "/mnt/boot/modules/$KERNELVER/squashfs.ko"
+umount /mnt/boot
+
 #mount pdrv
 mount_sfs "$PDRV_SPEC" "pdrv"
 [ $? -eq 0 ] || fatal_error "$mount_sfs_RET"
@@ -615,7 +621,9 @@
 	fi
 fi
 ZDRV_MNTPT=''
-sortout_sfs_spec "$DISTRO_ZDRVSFS" "$ZDRV"
+#sortout_sfs_spec "$DISTRO_ZDRVSFS" "$ZDRV"
+#raspberry pi, need to support two different zdrvs for armv6 and armv7 kernels
+sortout_sfs_spec "zdrv_raspup_$(uname -r).sfs" "mmcblk0p1:/zdrv_raspup_$(uname -r).sfs"
 if [ "$sortout_sfs_spec_RET" ];then
 	ZDRV_SPEC="$sortout_sfs_spec_RET"
 	mount_sfs "$ZDRV_SPEC" "zdrv"
Is this re-write of the init script going to eventually be merged with the init in woof-CE, or is it a separate experiment?

I'm not sure if the Pi1/Pi0 has enough RAM (512MB) to run completely in RAM, but it opens the possibility to running frugally in a FAT formatted SD card without reformatting/writing an image file to it.

I am planning to (eventually) figure out how to cross compile a kernel with AUFS support, but it is nice to already be able to play with the pre-compiled kernels.

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

Re: RE: A reflection on where it's at

#76 Post by gyro »

woodenshoe-wi wrote:I just wanted to let you know that after replacing the 386 binaries in the initrd.gz with ARM binaries I was able to use your init script on my Pi2 (1GB RAM) with only two small modifications.
Thanks.
The latest version contains even less binaries.
woodenshoe-wi wrote:Is this re-write of the init script going to eventually be merged with the init in woof-CE, or is it a separate experiment?
I don't know.
When I get to the end, i.e. an "initrd.gz" I can use for my every day puppy, including all my bright ideas that worked, we will have 3 options.
1. Replace the current "init" in woof-ce with one based on this one.
2. Port some of the stuff into the current woof-ce "init".
3. Leave it is as a stand alone "initrd.gz".
Whatever happens, since I can boot "off-the-rack" puppies with it, I intend to use it with my every day woof-ce based puppy.

gyro
Last edited by gyro on Sun 30 Jul 2017, 03:22, edited 1 time in total.

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

Updated version

#77 Post by gyro »

I've uploaded new versions to http://www.fishprogs.software/puppy/initrd/initrd.gz and http://www.fishprogs.software/puppy/ini ... verlay.sfs.
Both need to be downloaded, since the "ydrv_overlay.sfs" now contains an updated "extra_sfs", updated "initmodules" and new bootspecs utilities.

Changes in this 30 July version:

1. "extra_sfs" now works in puppy with no mounted partitions, i.e. pupmode=5 and pupmode=21.
It will automatically mount the partition containing puppy...sfs so sfs files can be selected, and then umount it on exit.
If you want to include sfs files from other partitions you will have to manually mount these partitions before running "extra_sfs".

2. "initmodules" now works. It stores a "PIMOD=" parameter directly in BOOT_SPECS.

3. Both "extra_sfs" and "initmodules" use the new BOOT_SPECS utilities, "bootspecs2tmpbs", "variable2tmpbs", and "tmpbs2bootspecs". These are included in
"bootspecs2tmpbs" retrives BOOT_SPECS, from inside the initrd.gz if necessary, and stores it in /tmp.
"variable2tmpbs" is called by utilities like "initmodules" to store their data in BOOT_SPECS.

Code: Select all

variable2tmpbs -q PIMOD "$MODFILELIST"
"variable2tmpbs" calls "bootspecs2tmpbs" if necessary.
"tmpbs2bootspecs" restores BOOT_SPECS to it's nornal place, inside initrd.gz if necessary. It's automatically run by rc.shutdown.
Running any of these utilities with a "-h" parameter will display some usage information.

4. The "init" script now uses "time of last modification as seconds since Epoch" to specify each sfs in BOOTCONFIG.
A deficiency in the current system is that if an sfs is replaced by one with the same name but differrent contents, rc.update will not see the difference.
rc.update does not care abouit the names of the sfs's, it just checks if the provided information is different from the previous one. e.g. replace the adrv with one containing a different set of applications.

5. The "init" script has some improvements in the messages it produces. The output from fsck is now sent to "/initrd/tmp/bootinit.log" as well as the console.
It's also been trimmed by removing some unused messages.

6. The "initrd.gz" has been further trimmed by removing further unused binaries, so it is a smaller download.

Edit: Sorry I forgot to mention that the ydrv_overlay.sfs now includes a 32bit yad. I got tired of "extra_sfs"->"Add" not opening in the correct directory with older versions of yad.

gyro

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

overlayfs, tmpfs, and the kernel

#78 Post by gyro »

overlayfs, tmpfs, and the kernel:

I have read reports on the net that overlayfs is unreliable, and in particular when using tmpfs as the top (read-write) directory.
I have also read reports on the net that tmpfs is ok if it is configured in the kernel with xattr support.

My experience with this "initrd.gz":
I have had no reliability problems in the many, many boots of the 4 different puppies I have used in testing.
I am aware of only 1 system hang using tmpfs as the top directory, but that was using a kernel that was not configured with xattr support for tmpfs.

Unfortunately the only puppy containing a kernel configured with both the following:

Code: Select all

CONFIG_OVERLAY_FS=m
CONFIG_TMPFS_XATTR=y
is LxPupSc 17.07.25.
So I've done a bit of kernel compiling using the kernel-kit from woof-ce.
I compiled an appropriately configured 4.9.39 32bit PAE kernel in xenialpup 7.0.8.1.
I'm currently successfully using this kernel to test this "initrd.gz" on xenialpup 7.0.8.1 and tahr 6.0.6.
I'm testing slacko 6.9.9.9 in pupmode=12 only, thus avoiding using tmpfs as the top directory. Slacko's kernel does not have xattr support for tmpfs.
I have not tried using the LxPupSc 4.12.3 kernel with slacko.

Note: This kernel package does not contain any firmware, you need to supply an fdrv.
I use http://www.fishprogs.software/puppy/fir ... 170627.sfs.

Downloads:
http://www.fishprogs.software/puppy/ini ... ae.tar.bz2
http://www.fishprogs.software/puppy/ini ... z2.md5.txt
http://www.fishprogs.software/puppy/ini ... sha256.txt

gyro

woodenshoe-wi
Posts: 109
Joined: Sat 29 Jul 2017, 03:16
Location: Wisconsin

#79 Post by woodenshoe-wi »

I will have to modify you new version for ARM use and try it out :D

I added yad to DISTRO_PKGS_SPECS-raspbian-stretch so I don't need to install it but I need the ARM version of course.

After realizing that I forgot to copy the right version kernel to the SD card :oops: I have my Pi1 booting from a SD card that still has its factory FAT formatting, no repartitioning, no ext2 filesystem, no need to write an image file to it... So I am excited about that. A big thanks for your work on overlayfs support!

Two feature requests, or maybe I should try to implement this in an ARM fork of your init,

- A raspberry pi does not have a bootloader that offers any type of menu, so having the ability to choose which installation to boot using a config file to make a boot menu would be nice.

- A pi1/pi0 only has 512MB RAM and can't load any sfs files to RAM anyway, so the SD card will have to remain mounted, but on boot if I understand your init script correctly the entire content of raspupsave.ram.sfs gets copied to RAM. Having support for a pupsave.2fs file would get around this limitation but on a SD card or USB stick it should have a tmpfs overlay which means snapmergepuppy which means AUFS... I did manage to modify kernel-kit enough to get it to cross compile a kernel yesterday, but I haven't tested if it actually works.

I don't know if you want to add AUFS support to your OverlayFs based init, add OverlayFs support to the AUFS based woof-ce init, or if it would be best to have a separate init for ARM use that would have parts from both init scripts. I would like to always be able to boot even if the kernel doesn't have AUFS support, but when trying to keep RAM usage down AUFS could be helpful.

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#80 Post by gyro »

woodenshoe-wi wrote:Two feature requests, or maybe I should try to implement this in an ARM fork of your init,

- A raspberry pi does not have a bootloader that offers any type of menu, so having the ability to choose which installation to boot using a config file to make a boot menu would be nice.
Sorry, I won't be doing this since it is pi specific.
The focus of this new init at the moment is firmly on booting an ordinary PC using a directory on a Linux file system for a save folder. I haven't even started on support for booting from CD yet.
woodenshoe-wi wrote: - A pi1/pi0 only has 512MB RAM and can't load any sfs files to RAM anyway, so the SD card will have to remain mounted, but on boot if I understand your init script correctly the entire content of raspupsave.ram.sfs gets copied to RAM. Having support for a pupsave.2fs file would get around this limitation but on a SD card or USB stick it should have a tmpfs overlay which means snapmergepuppy which means AUFS... I did manage to modify kernel-kit enough to get it to cross compile a kernel yesterday, but I haven't tested if it actually works.
A savefile doesn't need aufs. There's no reason that this overlayfs init should not support a savefile. The top directory (the rw one), has to be on a Linux file system, this can be provided in many ways, the simplest of these is to use a directory on a Linux partition.
But it could also be provided by mounting the Linux filesystem inside a savefile and using it's mountpoint as the top directory. This is what puppy has been doing for years using aufs and uniionfs.
From my perspective it's just a whole lot of extra code that's required to get to the same point. We already know how to do this.
So, savefile support could be added to this init using overlayfs, but I won't be even considering it until after all the fun of testing new possibilites is finished, and I've still got a couple of those.
woodenshoe-wi wrote:I don't know if you want to add AUFS support to your OverlayFs based init, add OverlayFs support to the AUFS based woof-ce init, or if it would be best to have a separate init for ARM use that would have parts from both init scripts. I would like to always be able to boot even if the kernel doesn't have AUFS support, but when trying to keep RAM usage down AUFS could be helpful.
I have thought of a hybrid overlayfs/aufs init, but for a rather different reason.
Overlayfs is supposed to be very efficient, so it might have better performance with lots of layers, and it supports creating read-only overlays with no read-write layer, (aufs can't do that), but it doesn't support changing the layers in the stack. So I have thought of loading all the sfs's into a read-only overlay and then using this as the bottom layer in a 2 layer aufs stack. Then we could still use "sfs_load on the fly".
Although I doubt that this will come to fruition since one of the drivers behind exploring overlayfs is the possibility that the day will come when patching the kernel with aufs will no longer work.
On the other hand, overlayfs is in the kernel, so we are not putting ourselves at any more risk by using a hybrid than we are by using aufs only.

gyro

Post Reply