Reclaiming root disk space

Essentially my offline update to 42.3 failed due to low disk space on root. I am trying to free up disk space to try and restart the update. None of my snapshots load anymore.

My root is a 40gb btrfs system.

I have looked at various threads on different sites and conclude that the disk space issue is likely to do with snapshots. I have deleted one pre- and post- snapshot, but this has not made a difference.

Any suggestions to try and diagnose/free up space?

Some pictures of ‘btrfs fi /’, snapper and ‘df -h’ are attached and available at


sudo snapper list

you can see all the snapshots


sudo snapper rm STARTNO-ENDNO

you can delete a range of snapshots.

Many thanks for the response. The output of

snapper ls

Is as follows

Are there complications if I delete snapshots with the ‘userdata’ field completed with ‘important=yes’?

Apologies, spotted images weren’t loading in line. Output of

btrfs fi dr /


snapper ls

is below:

And output of:

df -h

Is below:

As your df -h shows that / is 100%, that is not really a snapshot issue.

Try to find out what is really out of proportion. Not an easy task. Maybe first look in /var/log.

Generally the way to go is to start at the top of the file system (in this case /) and then do (as root) du -sh * to see what might be too large:

cd /
du -sh *

then cd to that directory and repeat the du -sh * until you find the culprit.

Many thanks for this advice. I have managed to identify that /var/log/ had 887mb. But .snapshots had the below output:

This obviously exceeds the total volume of the disk. I have gone through and deleted the majority of these and freed up 1.5gb by rebalancing the btrfs filesystem.

However, I still feel it sensible to free up more space. Does it cause issues if I delete snapshots that have 'important=yes" in the userdata column?

snapshots are not normal files they are meta files that represent changes to the file system. They are not easy to comprehend without a deeper understanding of the process. But very very roughly you can thing of them as difference files and the size shown is the space that would be affected if restored. Kind of sort of LOL :stuck_out_tongue:

Many thanks for this information.

Just to go back to my question, what are the implications/problems of removing snapshots that are marked as ‘important=yes’ in the ‘Userdata’ column of snapper ls?

A couple of things first:

  • Don’t use the traditional disk utilities, use

btrfs fi du
btrfs fi df 

  • The implication of removing snapshots is that you have no means to return to that snapshot. If the system is running fine apart from your rootfs being full, keep the oldest one, remove all others older than a week. Than reboot and take another look.

Why not? AFAICS it is. But since this is btrfs the normal disk tools are not reliable, See my other reply.

OK. My idea was that while df does not know about the snapshots, it would still report hopw much is free from it’s perspective.But I will try to not advice it anymore.

Nice watch here. by RBrown

Thanks for all the info on this, it has certainly been a learning curve.

Essentially I opted for the quick (but ultimately temporary solution). I removed many of the system snapshots by using:

snapper rm ##-##

(Where ## Is the snapshot number). After I had deleted the majority except the first and last entries, I then rebalanced the system:

btrfs balance start /

I didn’t add in any additional parameters in this case as the root partition is 40gb only.

In this manner I freed up 11gb. It is only a temporary fix as I need to ultimately resolve the snapper criteria to stop this in future.

The offline update was then able to complete.

The problem is now resolved and the thread can be closed.

Nice you are satisfied.

We generally do not “close” threads. There may be people that want to add remarks or ask further questions. Sayoing, like you did, that you are satisfied is OK.