My Kubuntu 12.04 system ran out of space on on the root partition and will not boot. The command df -h shows a lot of space available (with only 37% used):

/dev/sda2        45G   17G   29G  37%

The following page indicates that I should run the balance command:


$ sudo btrfs fi balance start -dusage=5 /mount/point

I'm not entirely confident that this is the best approach, but it is the only one I found. However, when I run that command, I get this error:

ERROR: error during balancing '/blah/blah/blah' - No space left on device

I get the same error with:

$ sudo btrfs fi balance start -dusage=1 /mount/point

What is the right solution?

  • If you have plenty of RAM and a stable power supply, then you could use a temporary ramdisk for some extra space. There is an example session at the bottom of this article. However the accepted answer below is a much simpler approach. Commented Jan 26, 2020 at 12:26

4 Answers 4


There are ways to get balance to run in this situation.

sudo btrfs fi show
sudo btrfs fi df /mount/point
sudo btrfs fi balance start -dusage=10 /mount/point

If the balance command ends with "Done, had to relocate 0 out of XX chunks", then you need to increase the "dusage" percentage parameter till at least one chunk is relocated.

if the balance command fails with:

ERROR: error during balancing '/blah/blah/blah' - No space left on device

You might actually need to delete files from the device to make some room. Then run the balance command again.

However, thanks to Marc's Blog: btrfs - Fixing Btrfs Filesystem Full Problems here is another option:

One trick to get around this is to add a device (even a USB key will do) to your btrfs filesystem. This should allow balance to start, and then you can remove the device with btrfs device delete when the balance is finished. It's also been said on the list that kernel 3.14 can fix some balancing issues that older kernels can't, so give that a shot if your kernel is old.

  • 7
    I've found that occasionally I've also needed to mount -oremount,clear_cache /mountpoint as well to fix the free space calculations. (They become corrupted...)
    – rrauenza
    Commented Jun 20, 2016 at 23:30
  • 1
    @rrauenza, thanks! You should add that as an answer :)
    – mwfearnley
    Commented Apr 3, 2018 at 11:20
  • Instead of running multiple times and increasing dusage each time, we can run with a higher dsuage and add a dlimit so that no more than 2 chunks will be rewritten on one pass. And we can do similarly for metadata chunks: sudo btrfs balance start -dusage=50 -dlimit=2 -musage=50 -mlimit=4 /mount/point (source) Commented Mar 25, 2020 at 4:29

I have found success with temporarily adding another BTRFS device, whether a spare flash drive, or better yet, a temporary file in RAM or another partition.

For a file in RAM, you'd have to create a RAM disk first. Once you decide on the location, create the file, then briefly add it to the BTRFS storage array. I created a simple script for my own usage (btrfs-balance-add.sh):


if [ "$#" -lt 3 ]; then

btrfs filesystem df "$LOC" # Print old
truncate -s "$SIZE" "$FILE" # If filesystem doesn't support "truncate", then use dd
modprobe loop # in case system hasn't yet loaded support for loopback devices
DEV_LOOP="$(losetup -f)"
losetup "$DEV_LOOP" "$FILE"
btrfs device add -f "$DEV_LOOP" "$LOC"
btrfs balance start -dusage=20 -musage=20 "$LOC" # feel free to tweak these values
btrfs device delete "$DEV_LOOP" "$LOC"
btrfs filesystem df "$LOC" # Print new
losetup -d "$DEV_LOOP"
rm "$FILE"


> sudo btrfs-balance-add.sh /mnt/ramdisk/delme.bin 1G /
  • I did this and it did end up working for me, but I've discovered after that it is very dangerous to use a ram disk! Use another drive instead. ohthehugemanatee.org/blog/2019/02/11/…
    – Ajay
    Commented Apr 6, 2022 at 5:15
  • This needs to be updated, now it is well documented that using ramdisk is very risky Commented Dec 20, 2022 at 17:28
  • Although the answer suggests to use a ramdisk (which is dangerous), the script given in the answer doesn't necessarily use a ramdisk, instead it uses a file-backed loopback device (which may be in a ramdisk) Commented May 13 at 5:11

I tried everything in the accepted answer, and Marc's blog, including incrementing the -dusage parameter and adding another block device, all to no avail. Even after deleting some files and freeing up a little space on the disk which was full, balance was not able to complete. For some reason it always seemed to be moving data onto the nearly full disk. In the end what did work for me was restricting balancing to the full device:

btrfs balance start -ddevid=<dev_id> <path>

where the dev_id can be found with:

btrfs fi show 
  • None of these worked
    – Met
    Commented May 5, 2019 at 19:10
  • This crashed my system and the volume became unavailable even I rebooted the system. I installed an volume with EXT4 and now I hope I can get rid of the very sensitive BTRFS system which I consider as a failure with lot of design problems. Commented Sep 10, 2019 at 16:03
  • Maybe its necessary to remove big files from specific storages, not any Commented Apr 10, 2023 at 22:29
  • My btrfs was mounted on / and /home together, but problems has gone only after removing .cache dir from /root Commented Apr 10, 2023 at 22:31

sudo apt-btrfs-snapshot delete-older-than 3d Deletes snapshots older than 3 days. As you move data around, snapshot data becomes out of place and actual data needs to be written in multiple places on the drive. This removes snapshots pertaining to old data in old locations and frees up those sectors for use again. I also recommend duperemove to deduplicate data and extents on the btrfs filesystem.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .