[takeda]

ZFS had this issue (I believe fixed) workaround was to pick up one large file that you wanted to delete and do `echo -n > /the/unimportant/file` once the file was reduced in size to 0, rm started to work again.

Not sure if that workaround would work in btrfs, but it worked on ZFS.

[chungy]

ZFS reserves 1/64 of every disk precisely so it can't be truly fully allocated. It leaves enough room to delete snapshots, truncate files, and so forth.

Mind that everything is copy-on-write, you can't do anything, even metadata changes, without allocating new blocks. It needs the reserve space.

[tobias3]

I had a ZFS bug once where they increased the amount reserved in a new release which caused my file system to be 100% and me unable to delete anything until I went back to the previous release.

Btrfs uses the the disk completely. This is harder to do (also compared to e.g. ext4 reserving a fixed amount of inode space which may be unused when the disk is full). At some point they added an in-memory "global reserve" metadata space which allows you to delete stuff even if the file system is full.

[rcthompson]

What happens if the file has already found its way into a snapshot? Then presumably that command will not free any space.

[takeda]

Well, rm wouldn't free the space either so you either would remove the snapshot or chose a different file.

[pletnes]

True. For me, I freed up space by nuking old snapshots, when I ran into this on btrfs.

[loeg]

See also: 'truncate -s 0 /the/file'

[pfranz]

Yep. I had this happen a few weeks ago (I'm not sure how much maintenance the server has had since it was set up 2-3 years previous). Thankfully, after seeing whatever the error was ("No space left on device" or something) and furrowing my brow it seemed obvious enough to try without having to search for a solution. It seemed just dumb enough to work.