23

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:

https://btrfs.wiki.kernel.org/index.php/Problem_FAQ#I_get_.22No_space_left_on_device.22_errors.2C_but_df_says_I.27ve_got_lots_of_space

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

MountainX
  • 17,948

4 Answers4

18

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.

MountainX
  • 17,948
  • 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 Jun 20 '16 at 23:30
  • 1
    @rrauenza, thanks! You should add that as an answer :) – mwfearnley Apr 03 '18 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) – joeytwiddle Mar 25 '20 at 04:29
4

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

#!/bin/sh

FILE="$1"
SIZE="$2"
if [ "$#" -lt 3 ]; then
    LOC="/"
else
    LOC="$3"
fi


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"

Usage:

> sudo btrfs-balance-add.sh /mnt/ramdisk/delme.bin 1G /
palswim
  • 5,167
  • 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. https://ohthehugemanatee.org/blog/2019/02/11/btrfs-out-of-space-emergency-response/ – Ajay Apr 06 '22 at 05:15
  • This needs to be updated, now it is well documented that using ramdisk is very risky – Shriraj Hegde Dec 20 '22 at 17:28
2

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
z7sg
  • 131
  • None of these worked – Met May 05 '19 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. – Peter VARGA Sep 10 '19 at 16:03
  • Maybe its necessary to remove big files from specific storages, not any – Demetry Pascal Apr 10 '23 at 22:29
  • My btrfs was mounted on / and /home together, but problems has gone only after removing .cache dir from /root – Demetry Pascal Apr 10 '23 at 22:31
0

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.

D337z
  • 1