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

[Dave Morley]

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

STEPS:
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

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

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

[Seth Arnold (seth-arnold)]

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'.

Thanks

[Oliver Grawert (ogra)]

@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 ?

[Seth Arnold (seth-arnold)]

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.

Thanks

[Oliver Grawert (ogra)]

(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)

[Zygmunt Krynicki (zyga)]

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.