Learn more about these different git repos.
Other Git URLs
Currently all Fedora images have a squashfs.img that is squashfs, with an embedded image file that contains an ext4 filesystem on which exists the root file system for booting. Ext4 was chosen in order to make the root file system read/write, where squashfs is read-only. But using overlayfs, it's no longer necessary to depend on a nested ext4 system.
Anaconda now has a feature to support creating a plain squashfs root file system, and dracut has all the parts to support assembly during boot as well. We should use it.
https://github.com/rhinstaller/anaconda/pull/2070#issuecomment-522000206
Future
Some time before the heat death of the universe
Not the end of the world. The problems with the existing device-mapper based overlay are ugly but well known.
The existing nested ext4 on squashfs might be contributing to #8581.
If/when this change happens, it affects livecd-tools's l-i-t-d feature for creating media with persistent overlays. Track coordination in this issue so they aren't caught surprised. https://github.com/livecd-tools/livecd-tools/issues/135
I posted sizes for various mksquashfs outputs in #8581, relevant to this issue is dropping the nested ext4 image reduces the size of the image by about 3%. And it also drops the consumer side /dev/loop1 CPU hit by 1/3; with this change it's necessary to profile /dev/loop0 (there is no loop1), and it never goes above 10% CPU. Details in: https://bugzilla.redhat.com/show_bug.cgi?id=1717728#c25
I can confirm inserting this plain squashfs.img into the ISO startsup without any changes, automatically using overlayfs. And once the following change appears in Fedora, which I just tested, Anaconda will also understand it. https://github.com/rhinstaller/anaconda/pull/2070/files
The gotcha right now, is even with level 22 selected, block size 256K, and plain squashfs image, the resulting squashfs.img is ~5% bigger than the current squashfs.img method. I think I know why, and have filed a bug here:
https://bugzilla.redhat.com/show_bug.cgi?id=1743029
NOTE: That means all "level 22" sizes mentioned before 20190818 might actually be level 19.
Two added advantages of plain squashfs (overlayfs) over nested ext4 (device-mapper):
-We're no longer limited to the baked in ext4 rootfs size, which right now limits debugging the environment. Anything requiring installation of debuginfos exceeds this space quickly. Instead the limit depends on the backing device: either RAM or an independent persistent file system layered using overlayfs.
-Folks depending on persistent write media, SoaS, and others using livecd-iso-to-disk, no longer get the inevitable blowup and corruption of their root file system, necessitating reset. Note lines 116-126. https://github.com/livecd-tools/livecd-tools/blob/master/tools/livecd-iso-to-disk.sh
So, I am not sure what you want releng to do here.
Decide if we want to move to this? It sounds like it has a lot of advantages. So, perhaps we try it out in rawhide and give a long ramp to the f32 release?
Is the default going to change or will we need to pass livemedia-creator something? (if so, might need some koji changes).
The default isn't going to change anywhere. Fedora would need to make the change, by using livemedia-creator --squashfs-only
The two changes needed to support it are these PRs, but I'm not sure what version of lorax and anaconda contain those changes.
https://github.com/weldr/lorax/pull/822 https://github.com/rhinstaller/anaconda/pull/2070/
It is valid to consider #8646 and #8581 together or separately, but I figured on separate just because it might be easier to troubleshoot any face plants. And also get a more clear picture of the size and time increase on the compose side, and see if those are acceptable tradeoffs for consumer side CPU reduction and performance improvements.
Which means we need koji changes, because we use pungi that in turn just calls koji to make the live media.
So, either we need to change the default in koji, or koji needs to grow a way for us to configure this. Can you open a koji ticket? Or would you like me to do so?
https://pagure.io/koji/issue/1622
?
Thanks!
Small clarification: this presently will affect so-called "Live" ISOs only, not netinstall or DVD. https://github.com/rhinstaller/anaconda/pull/2070#issuecomment-523505070
Metadata Update from @kevin: - Issue tagged with: backlog
Metadata Update from @amoloney: - Custom field blockedby adjusted to https://pagure.io/koji/issue/1622
This issue is blocked by https://pagure.io/koji/issue/1622 before it can be resolved.
Hi @chrismurphy,
is this feature still desired? If so can you coordinate with Koji devs on the blocking ticket? If this feature is no longer required releng will close this ticket in upcoming weeks.
Performance would be better by removing the nested ext4 image in the squashfs image. So yes the feature is still desired.
But it would be incrementally better to make the image a btrfs seed.
Btrfs seed advantages:
drop-in replacement, can be mounted and used just like the squashfs image is being used now
on-the-fly checksumming for every read, ensuring corruption isn't replicated during installations, no matter the destination file system; obviates the need for the very slow out of band ISO md5sum check
optional optimization for Btrfs installations (the default on desktops) using Btrfs seed->sprout replication feature, to improve performance. This would require some additional work in the installer to take advantage of it but wouldn't be a requirement.
Login to comment on this ticket.