I’m not sure if snap developers monitor launchpad or not, so I thought I’d report LP bug #1867415 here as well:
Boot with e.g. the current ubuntu-20.04-desktop-amd64.iso. Open a terminal and run df -h. You’ll notice:
Filesystem Size Used Avail Use% Mounted on
/cow 2.0G 434M 1.5G 23% /
This means that the tmpfs file system needs 400 MB RAM for snaps. Xenial didn’t have snaps and needed only 14 MB tmpfs. Snap shouldn’t consume tmpfs RAM space, it should only use squashfs disk space.
I think this is caused by function Install() in snap/squashfs/squashfs.go, which hardlinks /var/lib/snapd/seed/snaps/* to /var/lib/snapd/snaps/*.
Hardlinks cause overlayfs copy-ups in live CDs and LTSP.
Maybe the next option, symlinks, should be preferred in overlayfs.
These snaps are preinstalled in the live CD, you don’t need to install anything.
Check the disk space:
# df -h
Filesystem Size Used Avail Use% Mounted on
/cow 2.0G 434M 1.5G 23% /
These 400+ MB there shouldn’t exist, the tmpfs use should be less than 20 MB. They are caused by this line in squashfs.go:
if err := osLink(s.path, targetPath); err == nil {
When using ln instead of ln -s in overlayfs, the source file is modified in order to update its hardlink count. This causes a “copy-up” to RAM. So if a live CD has 400 MB worth of snaps, it causes 400 MB of RAM to be wasted because of those copy-ups.
That logic in squashfs.go should be reworked, so that symlinks and not hard links are used in live CDs, i.e. the next line in squashfs.go:
if filepath.Dir(s.path) == dirs.SnapSeedDir && os.Symlink(s.path, targetPath) == nil {
The logic now is:
try hardlinks, then symlinks, then cp.
It should be possible to just drop the hardlink call:
try symlinks, then cp.
Hardlinks have many issues, like the one described above; also they’re not supported in all file systems; and finally they won’t work at all if the target dir is on a different file system than the source dir. Maybe defaulting to relative symlinks is better in all cases.
There is work on going to do some of the things seeding does at image build time. I’m not sure if creating these hard links is part of that, if it is then this issue will go away. I’m also not sure if that’s going to be ready for focal though.
mwhudson, if snap can’t do it in time for focal, maybe it would be worth it to put “casper” in the affected packages, to do a quick ln -s on boot, e.g. at the end of 55disable_snap_refresh?
400 MB is a lot of additional RAM in the “minimal requirements” for running the Ubuntu live CD…
