I’m investigating app sandbox use cases for EROFS, and I wonder if it’s possible for snaps to add EROFS as an alternative way.
First, EROFS has been landed in main distros such as ubuntu, debian, fedora, opensuse, gentoo, WSL, etc.
Second, Curently EROFS can do incremental update between images with data deduplication in addition to compression. Laterly we’d also like to add self-contained verfication and encryption support.
Currently such incremental update approach is landed with Nydus image service for container images, also see. But I’d also like to develop this feature to erofs-utils if other use cases like app sandboxes need it.
My company is using snaps and I’m working on this effort to see if we can use less bandwidth for our IoT setup. When I was investigating this, I found snaps are using squashfs, and I thought: oh, I remember reading about this modern replacement for SquashFS on LWN, which is coverage of your talk on the 2023 Linux Storage & Filesystem Summit.
Then I did a web search on EROFS and Snap, and I found this forum post FROM YOU proposing to use it for snaps ! Did you get any follow-up on your message?
hi Canonical, are you paying attention? Here’s THE person from EROFS proposing to add EROFS as alternative to packaging for Snaps… it looks like there’s no public response!
FWIW I’m not associated with Canonical and can’t say what they will and won’t do. I do think it’s important though to highlight Snaps aim for compatibility for about 12 years of distributions. This is why we use LZO compression rather than say ZSTD, because older kernels don’t have it. There are a lot of users on Ubuntu 16.04 still.
Snapd could gain support for new backends, but the practicality is they’d be unlikely to be the only offered option for at least another decade based on commercial rather than purely technical reasons, it’d be the server providing different versions to different users based on client support or similar, when it was discussed similarly for compression alone.
It should also be noted that the integration of snaps in Ubuntu Core (which is the bigger commercial part around snaps) does require that the kernel snap can be loop mounted from the respective boot-loaders directly without any unpacking etc to load kernel and initrd from it.
So i.e. grub would need to have full support for EROFS on that level to make sure it matches the current secure boot implementation in use …
@ogra assuming I can patch snapd and snap pack command for doing the actual snap creation and ofcourse snapcraft itself do erofs snaps.
Do you think there will be a fundamental blocker on achieving something like that? Since I run snaps on a Yocto-based image, patching those software is not an issue. I already use EROFS for rootfs and am exploring the ability to have something faster for snaps as well, since we’d have very large snaps so every bit of performance matters.
Well, I think it would need a lot more research and probably some special case handling in snapd, i.e.:
If we can not make all bootloaders that are used in UbuntuCore handle erofs, snapd would have to learn to handle kernel and base snaps only when they use squashfs and refuse any erofs snaps here…
Another issue is that Canonical still fully supports snaps on 16.04 (at least for one more year) which IIRC used a 4.x kernel … erofs only landed in the 5.x cycle so such snaps would simply not work there…
I went ahead and did some work in this area. Since my usecase is snapd-on-Yocto where the RootFS is not a snap, I don’t have to worry about many edge-cases there.
My work is in-progress but I was able to test things with some manual magic, till I can “teach” snap install to correctly handle erofs (almost there actually).
I extracted an existing snap, and made that erofs, then just updated the systemd unit to point to the new file and changed filesystem to erofs and it just worked.
Anyways, I’ll finish the above work and make sure snap install supports that as well. For snapcraft pack, I’ll just create the snap the traditional way, extract it and repack again. Once this stuff is stable enough, I’ll sure make changes to snapcraft as well. Will probably just add a snapcraft pack --container erofs,squashfs flag so that nothing needs to change in the snapcraft.yaml format
I do understand this stuff doesn’t align with the upstream vision currently but maybe if we end up producing good performance numbers, it might become of interest here as well.
Hi @om26er,
I contacted with Canonical folks about a month ago.
I think we agreed to add a minimal EROFS runtime support to snapd sometime (after ubuntu 25.10 is out (Try to Cc @zyga too…)), so at least users can specify local erofs image, and it doesn’t impact all current squashfs-based snap images.
Also EROFS supports many advanced features, I think after a minimal support we could explore them then.
! Did you get any follow-up on your message?