Hardlinking snaps wastes 400 MB tmpfs RAM in live CDs
Bug #1867415 reported by
Alkis Georgopoulos
This bug affects 2 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
snapd |
Fix Released
|
Critical
|
Michael Vogt | ||
snapd (Ubuntu) |
Fix Released
|
Critical
|
Unassigned |
Bug Description
Boot with e.g. the current ubuntu-
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/
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 |
tags: | added: rls-ff-incoming |
Changed in snapd (Ubuntu): | |
importance: | Undecided → Critical |
Changed in snapd: | |
assignee: | nobody → Michael Vogt (mvo) |
Changed in snapd: | |
importance: | Undecided → Critical |
Changed in snapd (Ubuntu): | |
status: | In Progress → Fix Committed |
Changed in snapd: | |
status: | In Progress → Fix Committed |
Changed in snapd: | |
status: | Fix Committed → Fix Released |
Changed in snapd (Ubuntu): | |
status: | Fix Committed → Fix Released |
Changed in snapd (Ubuntu): | |
status: | Fix Released → Triaged |
Changed in snapd: | |
status: | New → In Progress |
Changed in snapd (Ubuntu): | |
status: | Triaged → In Progress |
Changed in snapd: | |
milestone: | none → 2.45 |
Changed in snapd (Ubuntu): | |
status: | Fix Committed → Fix Released |
To post a comment you must log in.
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: /forum. snapcraft. io/t/hardlinkin g-snaps- wastes- 400-mb- tmpfs-ram- in-live- cds/15980
https:/
I also applied a temporary workaround in LTSP: /github. com/ltsp/ ltsp/blob/ master/ ltsp/client/ init/55- snap.sh# L31
https:/