Hardlinking snaps wastes 400 MB tmpfs RAM in live CDs

Bug #1867415 reported by Alkis Georgopoulos on 2020-03-14
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
snapd
Critical
Michael Vogt
snapd (Ubuntu)
Critical
Unassigned

Bug Description

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.

summary: - /var/lib/snapd/snaps needs 400 MB tmpfs RAM on live CDs
+ /var/lib/snapd/seed/snaps needs 400 MB tmpfs RAM on live CDs
description: updated
summary: - /var/lib/snapd/seed/snaps needs 400 MB tmpfs RAM on live CDs
+ Hardlinking snaps wastes 400 MB tmpfs RAM in live CDs
description: updated
description: updated
Changed in snapd:
status: New → Triaged
Alkis Georgopoulos (alkisg) wrote :

I think an acceptable solution is to just completely remove the "try to hardlink" logic from squashfs.go, and default to the "try to symlink" logic instead. Symlinks work in a lot more cases than hardlinks.

I cross-posted this in snap forums:
https://forum.snapcraft.io/t/hardlinking-snaps-wastes-400-mb-tmpfs-ram-in-live-cds/15980

I also applied a temporary workaround in LTSP:
https://github.com/ltsp/ltsp/blob/master/ltsp/client/init/55-snap.sh#L31

tags: added: rls-ff-incoming
Changed in snapd (Ubuntu):
importance: Undecided → Critical
Dimitri John Ledkov (xnox) wrote :

I think we have a few options here:

1) For Desktop, Run /usr/lib/snapd/snap-preseed on the desktop images, this should complete most seeding on the base squashfs, without wasting tmpfs space and speed up boot

2) For Server, we might need to run /usr/lib/snapd/snap-preseed on the up-most layer, such that install boot is without symlinks, whilst the in-target first boot is still slow. Because server uses multi-layer squashfs.

Changed in snapd:
assignee: nobody → Michael Vogt (mvo)
Michael Vogt (mvo) wrote :

A fix for this is now merged into the 2.44 release branch.

Changed in snapd (Ubuntu):
status: New → In Progress
Changed in snapd:
status: Triaged → In Progress
Alkis Georgopoulos (alkisg) wrote :

Would it make sense to somehow backport this to bionic for subsequent 18.04.x live CDs?

Michael Hudson-Doyle (mwhudson) wrote :

snapd releases are backported to stable releases as a matter of course so it will get there sooner or later.

Changed in snapd:
importance: Undecided → Critical
Michael Vogt (mvo) on 2020-03-27
Changed in snapd (Ubuntu):
status: In Progress → Fix Committed
Changed in snapd:
status: In Progress → Fix Committed
Michael Vogt (mvo) on 2020-04-02
Changed in snapd:
status: Fix Committed → Fix Released
Changed in snapd (Ubuntu):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers