ubuntu-image should reserve 1-5% for root when creating filesystems

Bug #1635258 reported by Dave Morley on 2016-10-20
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ubuntu Image

Bug Description

Filling the writable system means you can't uninstall or install apps and causes issues in the system as a whole.

1. Flash and boot the ubuntu-core 16 image on dragonboard
2. Run the command df -h to list the available space on various mounted partitions
3. Using fallocate, occupy all the available space on /writable partition
4. Install some snaps to occupy the remaining space to make sure df -h output is similar to http://paste.ubuntu.com/23273852/

5. There would be a point where, snap install and other snap commands would start failing with following error

I expect 5% to be reserved so the system is still usable

You can completely fill the system and then not be able to do anything with the packages on it.

Dave Morley (davmor2) on 2016-10-20
description: updated
Seth Arnold (seth-arnold) wrote :

I doubt the utility of reserving 5% of disk space for any specific group.

If you set the group to one of snapd's groups, then snapd can of course fill the disk with too many 'snap install' commands.

If you set the group to one that snapd does not run as, then snapd cannot use the free space when trying to use 'snap remove'.


Dave Morley (davmor2) on 2016-10-20
summary: - File system should 5% Ubuntu-image
+ File system should reserve 5% Ubuntu-image

@seth: snapd runs as root, what we want to achieve here is that snapd can still operate when the diskspace gets used up by installed snaps (this used to be the original intend of the 5% that all filesystem creations tools reserve by default in traditional classic installs).

will this not be the case anymore with the setup we use currently ?

summary: - File system should reserve 5% Ubuntu-image
+ ubuntu-image should reserve 5% for root when creating filesystems
Seth Arnold (seth-arnold) wrote :

ogra, if we set up the 5% for e.g. group snapdaemon, start snapd with the snapdaemon group in supplementary groups, and be very careful to drop the snapdaemon group before installing, unpacking, running anything, etc., we might be able to use the magic group correctly. It'd be fiddly to ensure the group never 'leaks' to any less-privileged systems.


Oliver Grawert (ogra) wrote :

(this info was in the original bug, just carrying it over):

ogra@dragon:~$ sudo dumpe2fs -h /dev/mmcblk0p2|grep "Reserved blocks"
dumpe2fs 1.42.13 (17-May-2015)
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)

Michael Vogt (mvo) on 2016-11-30
summary: - ubuntu-image should reserve 5% for root when creating filesystems
+ ubuntu-image should reserve 1-5% for root when creating filesystems
Barry Warsaw (barry) on 2016-11-30
no longer affects: ubuntu-image (Ubuntu)
Zygmunt Krynicki (zyga) wrote :

My personal opinion is that we need to introduce quota support. Specifically ext4 project quotas, where each snap would be a distinct project. Then we can reliably measure and control disk space used by each snap. Separately snapd has some more sensible behavior in face of operations that could consume all disk space but I think that is less relevant as applications are the bigger problem right now.

affects: snappy → snapd
Changed in snapd:
status: New → Triaged
importance: Undecided → Medium
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers