Configure number of old revisions to keep

snapd
1

I have a system with a small SSD. I would like some configurable policy for automatic removal of old snap versions.

It is annoying to require the user to ‘snap list --all’ and then iterate ‘snap remove --revision #### $snapname’ for each old version that is hanging around when they notice that disk space is low.

I know old versions are kept so that ‘snap revert’ works, but I would like to see a sensible default and tunable controlling retention of disabled snaps.

3 Likes
2

snapd only keeps three revisions. Are you seeing more?

3

I had three. I didn’t see a reason for keeping two old core snaps, especially given how old the 3rd was. I felt that 2 would have been sufficient.

4

We can surely look at making this configurable. I won’t be able to give you a timeline for this yet, but adding to the backlog.

1 Like
5

Has there been any progress investigating adding support for a configurable number of snap revisions to store?

2 Likes
6

I too would like to see some way to snap purge to remove old releases. My disk is full and it feels like 1999 to be using tools like ncdu and du to micro-manage the space.

3 Likes
7

I should’ve updated this when the code landed (I thought I had! maybe it’s somewhere else but I can’t find it).

You can configure the number of revisions to keep with

snap set system refresh.retain=N

N can’t be less than 2, for now at least.

2 Likes
8

Has nobody filed an official issue?

9

Someone has, and the result was that you can go down to 2 retained revisions now… which is the minimum possible with the built-in automatic “rollback on error” feature that snaps have…

10

But rollbacks are purges to me describe entirely different things. Surely they obviously are so?

11

Snaps are atomic, meaning the whole thing needs to be on disk before anything is done with it, at the same time snaps have plenty places where they can enable self-tests at different stages of their runtime… I.e. imagine you package a webserver into your app snap… it can use snap hooks to do self focused health tests on different levels if port 80 is open… if the test fails, the snap automagically goes back to the former (known good) installed revision on disk… for this you need the former revision on disk (since this feature needs to work reliable offline and you also can not guarantee the last working version is still on the server)

while not many desktop snaps make use of this feature today, plenty of server snaps as well as the kernel snaps (which are now also used on desktops) do… given that snaps are highly compressed squashfs files, the lost disk space is really neglectable in that light…

1 Like
12

I see. So because they’re entirely self-contained compressed filesystems, if the revisions are removed, the snap is functionally “purged” from the system.

13

well, you can even “force purge” by using the … guess :slight_smile: … snap remove --purge option (which will prevent the snap from taking an automatic backup of your user data as they do by default in case you re-install it later) … you can also remove snaps by revision and technically work around the 2 revision limit through that but since that requires some advanced knowledge it is assumed that you know what you are doing in this case … snap help remove might be of value here

1 Like