Pseudo Full Install (testing)

[fredx181]

*** Pseudo Full Install ***

Discussed earlier in the Kennel Linux section and also I believe that @gyrog experimented with a similar setup for Puppy.
Here's my take for 'Dog' systems (using porteus-boot method, that I've now modified with additional option "pfull=..." (if used, it's a replacement for "changes=....")) see more info below.
Can be called as you like, e.g. "Frugal Full install" or "Hybrid install" or FFI (Funny Full Install )
Different from a regular full install is that no dedicated partition is needed, just a folder on some Linux filesystem (e.g. ext3) and of course it will take more space (than frugal install), as the filesystem is not compressed.
The setup in this case is that the main .squashfs (01-filesystem.squashfs) will be unsquashed to a directory (pfull/filesystem), see pic below, and after reboot (with pfull=..), the changes you make are being merged there (and deletions are directly deleted). Therefore no 'whiteout' or 'mask' files will be in use.
The "01-filesystem.squashfs" module will be disabled automatically when booted with pfull= cheatcode .
Still it has the benefits of a frugal install (is still a "layered" system, using overlayfs), e.g. possible to add extra .squashfs module(s) and pfull=EXIT:... cheatcode works too (save only on demand or at shutdown).

• When making a new build with mklive (bullseye, bookworm, daedalus, sid (NOT Buster)) this new pfull= option will be enabled (created initrd1.xz is modified for that), and the booted system includes a new menu entry:
  Menu > DDog Special > "Pseudo Full Install Setup"
  After having setup the "pfull' directory, you can reboot with pfull=.... (see also grub.cfg example below)

  

  Screenshot.jpg (80.31 KiB) Viewed 1349 times

• For on an existing build (bullseye, bookworm, daedalus, sid (NOT Buster)) or the "Starter Kit" by @rcrsn51) it's a bit more complex, you can make it work by re-creating initrd1.xz, required is:
  -- Install latest "upgrade-kernel" package (v1.15) (it includes separate script for only re-generate initrd) apt update; apt install upgrade-kernel.
  -- Run from terminal : mk-initrd, type or paste the kernel version and when done, a new initrd1.xz will be in /tmp, then copy it to your frugal install "live" folder (replace existing).

  

  2024-03-30_09-43-02.png (42.23 KiB) Viewed 1349 times

  -- Booting with this new initrd1.xz should have the pfull= cheatcode enabled, first, boot "normally" (with or without changes=)
  -- Then run below attached script to create the "pfull" directory in your frugal install folder (live)

  pseudofull-setup.gz

  Remove fake .gz and make executable

  (2.9 KiB) Downloaded 36 times

  (note that running this will work only when already booted with the modified initrd1.xz (with pfull= option included)

Example entry in grub.cfg:
(this assuming that the "pfull" directory exists already in /bworm/live, do NOT specify the pfull directory pfull=/bworm/live/pfull just pfull=/bworm/live (parent folder of "pfull" dir):

Code: Select all

menuentry "Bookworm Pseudo Full" {
insmod ext2
search --no-floppy --fs-uuid --set=root  34b10665-11c5-493c-9bff-f4f1e7db86f2
linux /bworm/live/vmlinuz1 noauto from=/bworm pfull=/bworm/live net.ifnames=0 
initrd /bworm/live/initrd1.xz
}

[fredx181]

When booting with pseudo-full, a side-effect can be (if using conky) that conky uses much more CPU, depending how big the pfull directory is.
For a new build with mklive the file /root/.conkyrc-port has been replaced with a fixed one (less complex calculations, less CPU usage).
But for an existing build, better replace it, attached "Conky-conf-fix.tar.gz" with the fixed configs (separated for bullseye, bookworm, etc..)

Conky-conf-fix.tar.gz

(2.31 KiB) Downloaded 35 times

EDIT:
Some other notes:

• Didn't test, but probably it makes no sense to do a remaster when booted with pfull= (e.g. with quick-remaster), in fact the pfull directory is already a remaster, and also doing it may not work as expected.
  (EDIT: Appears that remastering works, as @dcung reported: viewtopic.php?p=115714#p115714)
• With the setup as above, the content of the kernel .squashfs (e.g. k-6.1.0-18-amd64.squashfs) is not included in the pfull directory, but it's possible too of course by mounting it and then copy the files manually to pfull/filesystem (and disable the kernel .squashfs by renaming to ......bak), but I wouldn't advice it because having the kernel as separate module makes it easy to swap kernel if desired.

Will add here if I think of other important things to mention.

[fredx181]

For easy testing, here's bw_pfull.tar.gz archive, it's a minimal amd64 Bookworm openbox build with included initrd1.xz modified for pfull= support:
https://drive.google.com/uc?export=down ... UhI7sUMXb9 (Size: 460M)
Extract on a Linux formatted partition (e.g. ext3), so you get the bw_pfull directory on the root of that partition.
Then open a terminal in the bw_pfull/live/ directory and run ./setup-pseudofull
EDIT: This can be done from any distro booted, i.e. doesn't need to be done from a 'Dog' system.
The "pfull" directory should then be created there. Pseudo full installation finished.

Example for in grub.cfg (change the large UUID number to what it is for you):

Code: Select all

menuentry "Bookworm Openbox Minimal Pseudo Full" {
insmod ext2
search --no-floppy --fs-uuid --set=root 34b10665-11c5-493c-9bff-f4f1e7db86f2
linux /bw_pfull/live/vmlinuz1 noauto from=/bw_pfull pfull=/bw_pfull/live net.ifnames=0 
initrd /bw_pfull/live/initrd1.xz
}

Or if you want save on demand or at shutdown make it pfull=EXIT:/bw_pfull/live rather than pfull=/bw_pfull/live

[wiak]

Good to hear you got that all going Fred. I was a bit surprised you needed to create a pfull directory for the uncompressed read/write filesystem though, but though it had crossed my mind that PFI should be relatively easy to use with DebianDogs I never tried it. Because I'm 'on the move - house-wise - I haven't had time to look at DD folder structure, which I've forgotten... Off the top of my head I had thought simply unsquashing the 01filesystem sfs into changes folder would work using Porteus boot same like we do in KL distros (is the save folder called 'changes'? - that's what I remember it as). In KL, using current FirstRib initrd it is necessary to create an empty overlay such as 07dummy (doesn't have to be an sfs in KL of course and probably I could modify the FR initrd not to need that dummy, but I minimise risks of damaging the longtime stable initrd in not bothering tinkering with it too much for little gain...); I kind of thought some dummy 01xxx.sfs might have been necessary for PFI to work with DebianDogs, but I probably have that completely wrong... I certainly use the idea a lot in FirstRib/KL - not so much for remastering since I often just run in that PFI mode all the time and it also works with wd_multi distro type arrangements so the increased disk size used since uncompressed doesn't usually matter much to me anyway.

Gyrog ended up with something similar but all in one file rather than still using layers, which surprised me since keeping modules and firmware in their own layers with huge kernel seemed like to big a plus to remove, but I suppose there must be some advantage he finds in one folder arrangement only. I don't have time to try gyrog's implementation for Puppy at the moment. Jamesbond said he had PFI for FatDog from long time back; I meant to have a look at that implementation, but ran out of time.

EDIT (a bit offtopic but to do with booting including PFI variant): Just wanted to mention that, for me at least, the really simple wd_grubconfig script I use to find menu stanzas for KL/FR distros is my biggest life-saver since my memory is so bad I forget the grub boot stanza mechanisms I put into the FR initrd so the script quickly does it for me! Such a simple thing of course, but I really couldn't happily do without it (basically same code auto-used in wd_multi creations including Puppy variant so easy enough to modify/improve wd_grubconfig for DD use too and FatDog probably) - similar simple scripts for Puppy or DD or FatDog installation would make it much more likely for me to install them more frequently - as things stand, I'm fine with DD, but can never remember Puppy or FatDog grub stanzas and auto creating these with exact UUID and/or LABEL values makes life easy for lazy me...

[fredx181]

... I was a bit surprised you needed to create a pfull directory for the uncompressed read/write filesystem though, but though it had crossed my mind that PFI should be relatively easy to use with DebianDogs I never tried it. Because I'm 'on the move - house-wise - I haven't had time to look at DD folder structure, which I've forgotten... Off the top of my head I had thought simply unsquashing the 01filesystem sfs into changes folder would work using Porteus boot same like we do in KL distros (is the save folder called 'changes'? - that's what I remember it as).
...

Yes, well, unsquashing the 01filesystem sfs into the changes folder (and empty 01-filesystem.squashfs) was the first I experimented with and it worked, but finally I liked it more to be separated, changes= cheatcode for changes and pfull= for pseudo-full, as being separate cheatcodes and separate folders so you can easily switch (to one or the other) for one install without possibly interfering with each other.

Btw, if I may ask (just curious), where do you live now ? (if it's top-secret, just don't answer )

[wiak]

Btw, if I may ask (just curious), where do you live now ? (if it's top-secret, just don't answer )

In Asia... currently in Philippines but further down the road Thailand being considered

[dcung]

I thought I refresh my Bullseye, Bookworm, Daedalus, Sid mklive sets to have this new initrd1.xz.
Done - my marathon builds script still works, no modification necessary.

Started playing around with it.
I boot frugal, then use Menu > DDog Special > "Pseudo Full Install Setup" to create a pfull.
Moved the pfull to where I usually put my changes dir, modified my stanza, reboot and use pfull - works fine.
Happy to know that I can move pfull dir to wherever I want (same as changes dir).

I then re-run Menu > DDog Special > "Pseudo Full Install Setup" to create a 'new' pfull.
Note - I expected this, no surprise... Pretty smart detection...

2024-03-31-201120_909x549_scrot.png (64.82 KiB) Viewed 1001 times

.
.
.
.
.
Thanks Fred, for a 'new' thing for me to tinker with.

[Clarity]

Hi @fredx181

Fred, great ideology and structured approached. And it is reasonably consistent with @wiak offering presented. They, each, looks identical in desired achievement...just some minor name-changes

I ask each of you to consider to use the Sessions folder on Persistence as the GRUB2 stanza entry as well as the pseudo-full placement. This would, in effect, match how the current KL's GRUB2 stanzas will be seen by the user(s). I would expect that such a use of that folder will continue to solidify user efforts and be less work should user questions arise...as all of the distros running ONLY exist in that single folder-subfolder: Simply, on Persistence,in "/Sessions/pFull" for all KLs and DDOGs operations no matter Frugal or Full. And new or inexperience linux users ONLY see Persistence and Session to easily understand functionality, it make life easy for supporter of KLs and DDOGs.

If this containment is reasonable, I'm sure it will get proper consideration.

[wiak]

No time here to test this, but good idea to automate the PFI creation. Does it do it the other way round? i.e. Re-compress when so desired (for the remastering effect)?

[dcung]

Does it do it the other way round? i.e. Re-compress when so desired (for the remastering effect)?

It appears so.
I didn't do extensive test. Just installed dummy/test app (Grub-Customiser, & Grub2), made few conky changes, etc.
Run Quick-Remaster-Gui.
It made a new squashfs, backup the old one - just like what I am familiar with before.
I made sure I had no existing changes dir. I then reboot to use the 'remaster' - works.

Code: Select all

title bullseye-amd64-DDog.pf -  PFI
 uuid 3a6b1943-a582-4a6e-b75b-54ea0cb756ed
 kernel /bullseye-amd64-DDog.pf/live/vmlinuz1 from=/bullseye-amd64-DDog.pf noauto pfull=/bullseye-amd64-DDog.pf/
 initrd /bullseye-amd64-DDog.pf/live/initrd1.xz

title bullseye-amd64-DDog.pf -  Save changes
 uuid 3a6b1943-a582-4a6e-b75b-54ea0cb756ed
 kernel /bullseye-amd64-DDog.pf/live/vmlinuz1 from=/bullseye-amd64-DDog.pf noauto changes=/bullseye-amd64-DDog.pf/
 initrd /bullseye-amd64-DDog.pf/live/initrd1.xz

2024-04-01-131436_660x163_scrot.png (23.78 KiB) Viewed 937 times

2024-04-01-133224_454x368_scrot.png (60.55 KiB) Viewed 935 times

[wiak]

Does it do it the other way round? i.e. Re-compress when so desired (for the remastering effect)?

It appears so.
I didn't do extensive test. Just installed dummy/test app

That would be very handy in KL too. I'll add same commandline option to the FR initrd later. Actually should work via external simply modified w_init and once tested put also into the compressed FR initrd.

The more shared facilities/utilities between forum distros, the better for all I feel. Keeps forum distros ahead of external mainstream conventional offerings.

[fredx181]

Hi @dcung , thanks for testing !

I then re-run Menu > DDog Special > "Pseudo Full Install Setup" to create a 'new' pfull.
Note - I expected this, no surprise. ....

Yes, when booted with pfull= it probably will be "self-destructive" if pfull dir is in "live" (I didn't try it though) when creating a new pfull dir, as it will be deleted before unsquashing the 01-filesystem.squashfs .
So therefore disabled for safety.
(in fact similar as when doing "rm -rf /")
Good to hear that quick-remaster works too with pfull (only the options "Clear changes at reboot, etc.. make no sense , I think)

Btw, didn't mention yet, if you plan to permanently use a pseudo-full install, the 01-filesystem.squashfs has no use anymore and can safely be deleted.
(but then of course you can't boot with changes= anymore and cannot create a new pfull dir as it needs 01-filesystem.squashfs to be unsquashed)

[wiak]

Just an idea I have recently been considering for FR initrd that might easily and usefully be added to above scheme (I don't know how easy in your initrd though):

I was considering having a boot option that allowed upper_changes in KL to use any name the user wanted. That way could have several different bootable variants. Of course, that isn't really required when wd_multi is available anyway, which effectively provides similar and more functionality, but being able to change name of save folder is simpler in practice (but not so simple to put into FR initrd I suspect...).

But in making PFI scheme implementation such as your version, where you use pfull= in same way like changes=, you then specify path to where you want the pfull directory. I was thinking you might be able to instead specify full path including folder name? That way, on machine with lots of storage space, like many now have, it would be easy to have various different PFI uncompressed 'pfull_type' directories. Of course it is no big deal (and admittedly 'wastes' a lot of drive space) since as it stands user could simply have a utility that renames any other folder to "pfull" and reboot with that as the new pfull uncompressed save folder - but if the code wasn't any bigger to allow pfull= with full path and folder name, maybe slightly useful anyway??

[fredx181]

Just an idea I have recently been considering for FR initrd that might easily and usefully be added to above scheme (I don't know how easy in your initrd though):

I was considering having a boot option that allowed upper_changes in KL to use any name the user wanted. That way could have several different bootable variants. Of course, that isn't really required when wd_multi is available anyway, which effectively provides similar and more functionality, but being able to change name of save folder is simpler in practice (but not so simple to put into FR initrd I suspect...).

But in making PFI scheme implementation such as your version, where you use pfull= in same way like changes=, you then specify path to where you want the pfull directory. I was thinking you might be able to instead specify full path including folder name? That way, on machine with lots of storage space, like many now have, it would be easy to have various different PFI uncompressed 'pfull_type' directories. Of course it is no big deal (and admittedly 'wastes' a lot of drive space) since as it stands user could simply have a utility that renames any other folder to "pfull" and reboot with that as the new pfull uncompressed save folder - but if the code wasn't any bigger to allow pfull= with full path and folder name, maybe slightly useful anyway??

Perhaps I don't really understand what you mean, anyway: (not only trying to reply to you, also for to give general info about this):
Just like with changes= , the path you specify on the boot command line should be the parent folder.
i.e. changes=/b-worm will actually result in /b-worm/changes .
You can have multiple changes= configurations in grub.cfg or menu.lst as long as the path matches with existing location.
Same goes for pfull= , say you move the pfull dir to another location (as @dcung mentioned) you just need to specify the correct path to the parent folder of the pfull directory.
(edit: for example,. on some Linux partition, create e.g. "P_FULL" directory, move the pfull dir inside P_FULL and on the boot commandline : pfull=/P_FULL (or copy, but adviced to use "cp -a" from terminal, copying from filemanager can be tricky as it may choke on some filetypes).
So this way you can have multiple different "pseudo-full" installs from one distro release.
But... initially setting up a "pfull" directory will be in the "live" folder (where 01-filesystem.squashfs is located).
That's a limitation now, best may be to have choice for the location where "pfull" to be created, more complex though.

[dancytron]

Built a new Chromedog and got it booted and working.

These are the menu.1st entries I used to boot it directly out of the /bookwork/isodata directory for anyone who is still using grub4dos.

Probably won't have time to play with it today.

Code: Select all

title bookworm/isodata (sda1) noauto from=/bookworm/isodata/ changes=EXIT:/bookworm/isodata/ 
root (hd0,0)
kernel (hd0,0)/bookworm/isodata/live/vmlinuz1 from=/bookworm/isodata/ changes=EXIT:/bookworm/isodata/
initrd (hd0,0)/bookworm/isodata/live/initrd1.xz

title bookworm/isodata full install (sda1) noauto from=/bookworm/isodata/ pfull=EXIT:/bookworm/isodata/live
root (hd0,0)
kernel (hd0,0)/bookworm/isodata/live/vmlinuz1 from=/bookworm/isodata/ pfull=EXIT:/bookworm/isodata/live
initrd (hd0,0)/bookworm/isodata/live/initrd1.xz

[wiak]

You can have multiple changes= configurations in grub.cfg or menu.lst as long as the path matches with existing location.
Same goes for pfull= , say you move the pfull dir to another location (as @dcung mentioned) you just need to specify the correct path to the parent folder of the pfull directory.

Ah yes, sorry, of course you can have multiple pfull directories via different specified paths - I wasn't thinking straight.

[wiak]

For those (possibly many) who do not realise why a Pseudo Full Install arrangement is often preferable to a 'normal' read/write changes savefolder + read only main_root_filesystem.sfs typical frugal installation arrangement, here are the two main reasons (and the second reason is in many ways the most important reason):

1. By using the uncompressed main_root_filesystem as the read/write save folder, any changes are immediately written into that with no whiteout files being involved. The effect is an instant remaster. Users can, if they wish, later squash that save folder back up into a main_root_filesystem.sfs per typical frugal install arrangement with separate changes savefolder.

2. But consider this... Packages from upstream repos get upgraded with new revised versions quite frequently. A typical frugal install changes savefolder thus tends to quickly swell in size and the underlying main_root_filesystem.sfs becomes less and less relevant as its component parts get upgraded in the uncompressed changes savefolder (the effect is magnified if new packages are added). Indeed distros that are provided in iso form are usually out-of-date by the time a user downloads them, so on first upgrade of packages the uncompressed changes savefolder fills up with all the replacements (and in uncompressed form anyway). However, if the user instead makes a Pseudo Full Install arrangement out of the already out-of-date main_root_filesystem.sfs then that component can be removed entirely and the pfull savefolder will only have its component parts overwritten by new update without wasting space. In other words, using PFI actually saves storage space for any user that tends to upgrade their distro (which most do in normal daily use).

NOTE that it remains a trivial matter to back up your whole system. Simply create an sfs of you pfull savefolder and save that as your system backup, which will be as smaller in size than typical Puppy style save folder copied as a backup since the pfull backup is squashed up... Note that a normal Puppy-style 'saveFILE' is not stored in compressed format either, so a copy of that does not provide a small system backup of an upgraded system either. Of course a savefile isn't so easily written to, which some would argue offers some kind of 'protection' (but a corrupted savefile can be a big problem...), but most now use normal changes-style save folders and they are just as easily written to as suggested pfull type savefolder; no disadvantage to PFI at all really that I can think of.

[dancytron]

The only disadvantage I can think of is that you lose whatever the security advantage is of having most stuff in a read only format, but to really take advantage of that, you have to remaster all the time and not use a save folder or keep your save folder as minimal as possible.

I could see in a security paranoid scenario running the .squashfs without a save folder on random free wifi and then running pfull at home behind the firewall.

[wiak]

The only disadvantage I can think of is that you lose whatever the security advantage is of having most stuff in a read only format, but to really take advantage of that, you have to remaster all the time and not use a save folder or keep your save folder as minimal as possible.

I could see in a security paranoid scenario running the .squashfs without a save folder on random free wifi and then running pfull at home behind the firewall.

Yes you are correct, you'd have to keep remastering all the time to keep the savefolder as minimal as possible because the savefolder itself is read/write and never therefore secure.
Not many people constantly remaster their savefolder in practice I think.

BUT... by remastering after lots of changes you do get close to the best of both worlds: squashed and thus much smaller main root filesystem and very small savefolder (zero, immediately after remaster, being optimum for security in that unchangeable sense).

[BarryK]

wiak, dancytron,
I have been following this thread.
The above to two points are reasons why I have gone for btrfs and full-install in my experimental new QV.
btrfs supports read-write compression.

What is missing though, is encryption. ext4 supports fscrypt per-folder encryption, that I was using in EasyOS.
EasyOS encrypts /home and /files
btrfs has kernel patches for fscrypt, not yet mainlined -- I tried it but the kernel crashed.

The biggest problem for most people, is they would need to have a btrfs partition to install into. Which is likely to be the case if they had installed Fedora or OpenSuse. Otherwise, would have to create one.

Gparted requires 'btrfs-progs' installed, but there is another problem; many pups do not properly recognize btrfs partitions, for example it might not show up as a desktop icon -- but maybe that is older pups.

Anyway, if anyone wants to get a feel for what it is like to be running a pup-like full-frugal-installation in btrfs partition, I will upload QV soon. maybe in a day or two, but it will be pre-pre-alpha.
It will have snapshot support, which is one of the great things about btrfs.
QV ships as a drive-image, which you can write to a usb-stick. It is already a full-frugall-install in the drive-image, with a vfat esp boot partition and a btrfs partition -- the latter will automatically grow to fill the usb drive at first bootup.

[dancytron]

The only disadvantage I can think of is that you lose whatever the security advantage is of having most stuff in a read only format, but to really take advantage of that, you have to remaster all the time and not use a save folder or keep your save folder as minimal as possible.

I could see in a security paranoid scenario running the .squashfs without a save folder on random free wifi and then running pfull at home behind the firewall.

Yes you are correct, you'd have to keep remastering all the time to keep the savefolder as minimal as possible because the savefolder itself is read/write and never therefore secure.
Not many people constantly remaster their savefolder in practice I think.

BUT... by remastering after lots of changes you do get close to the best of both worlds: squashed and thus much smaller main root filesystem and very small savefolder (zero, immediately after remaster, being optimum for security in that unchangeable sense).

I used to do a quick remaster once a month or so or anytime a had a big upgrade and had little scripts to delete stuff and symlink browser profiles etc, but I decided it's way more trouble than it's worth.

[wiak]

...but I decided it's way more trouble than it's worth.

That echoes most of the way I usually also feel most of the time about lots of special arrangements and attempts for greater efficiency than what is often pretty efficient anyway.

[wiak]

wiak, dancytron,
I have been following this thread.
The above to two points are reasons why I have gone for btrfs and full-install in my experimental new QV.
btrfs supports read-write compression.

Yes, I've actually been following your QV btrfs thread. I remember some of the btrfs virtues because previous forum member rufwoof, who may or may not be around here still, used to detail various experiments he was doing with btrfs cow-type operations. I also long time back was a fan of User Mode Linux, which used copy on write filesystems, bit slow, but efficient (I understand uml is included in FatDog even today though that's nothing to do with btrfs of course and btrfs is probably a fast and efficient filesystem format too).

[dancytron]

...but I decided it's way more trouble than it's worth.

That echoes most of the way I usually also feel most of the time about lots of special arrangements and attempts for greater efficiency than what is often pretty efficient anyway.

The Debian Dog that runs 24/7 on my desktop except when I'm testing new stuff for the sake of testing has a /changes file that's 5 gig. I don't feel like messing with it. It's fine.

[fredx181]

...but I decided it's way more trouble than it's worth.

That echoes most of the way I usually also feel most of the time about lots of special arrangements and attempts for greater efficiency than what is often pretty efficient anyway.

The Debian Dog that runs 24/7 on my desktop except when I'm testing new stuff for the sake of testing has a /changes file that's 5 gig. I don't feel like messing with it. It's fine.

It's what you prefer of course, I do once in a while a remaster for my personal use, my 01-filesystem.squashfs is over 3G now, includes all my personal settings e.g. wifi config, firefox bookmarks etc..., and lots of extra software installed, including it's custom configurations. Also made an ISO from it.
Then copied it to USB (and can use Ventoy for ISO boot or just boot with manually created grub.cfg) also good IMO to have a solid backup of it, and to be able to boot exactly the same system from another computer (edit: but the latter may not always work out of the box, I must say).

[Clarity]

@wiak and @BarryK

BTRFS and its COW use. I have used QEMU's COW and COW2 for years, even before BTRFS. The achieved implementation is about the same. I was pleased when I saw Barry's work in his endeavors for a production implementation.

This year, 2024 is a year that many more users will find favor in learning of its value, implementation, and use in everyday workloads.

I view it to be rather difficult uphill for many users to grasp. Thus far, only few are reporting to distro owners their use cases or success.

BUT, it does have its merits particularly for its compression ability of the format and of the filesystem feature managements.