# [solved] BTRFS sucks : No space left on device

## toralf

I run every 1-2 weeks at my tindrebox into a situation where I do get :

```
/usr/lib/portage/python2.7/isolated-functions.sh: line 262: echo: write error: No space left on device

 * ERROR: app-text/xournal-0.4.8::gentoo failed (compile phase):

/usr/lib/portage/python2.7/isolated-functions.sh: line 262: echo: write error: No space left on device

 *   emake failed

/usr/lib/portage/python2.7/isolated-functions.sh: line 262: echo: write error: No space left on device

 * 

/usr/lib/portage/python2.7/isolated-functions.sh: line 262: echo: write error: No space left on device

 * If you need support, post the output of `emerge --info '=app-text/xournal-0.4.8::gentoo'`,

/usr/lib/portage/python2.7/isolated-functions.sh: line 262: echo: write error: No space left on device

 * the complete build log and the output of `emerge -pqv '=app-text/xournal-0.4.8::gentoo'`.

/usr/lib/portage/python2.7/isolated-functions.sh: line 262: echo: write error: No space left on device

 * The complete build log is located at '/var/log/portage/app-text:xournal-0.4.8:20150605-072431.log'.

/usr/lib/portage/python2.7/isolated-functions.sh: line 262: echo: write error: No space left on device

 * For convenience, a symlink to the build log is located at '/var/tmp/portage/app-text/xournal-0.4.8/temp/build.log'.

/usr/lib/portage/python2.7/isolated-functions.sh: line 262: echo: write error: No space left on device

 * The ebuild environment file is located at '/var/tmp/portage/app-text/xournal-0.4.8/temp/environment'.

/usr/lib/portage/python2.7/isolated-functions.sh: line 262: echo: write error: No space left on device

 * Working directory: '/var/tmp/portage/app-text/xournal-0.4.8/work/xournal-0.4.8'

/usr/lib/portage/python2.7/isolated-functions.sh: line 262: echo: write error: No space left on device

 * S: '/var/tmp/portage/app-text/xournal-0.4.8/work/xournal-0.4.8'

1   /var/tmp/portage/app-accessibility

4   /var/tmp/portage/app-text

0   /var/tmp/portage/sci-physics

...
```

 - an infamous bug of BTRFS here at 4.0.4-hardened-r3.

/me wonders if it is fixed in 4.1-rc* or if I shall switch away from that fs ?Last edited by toralf on Fri Jun 05, 2015 6:45 pm; edited 1 time in total

----------

## asturm

Experimental fs is experimental.

----------

## stephan-t

And really no leftover space in your drive?

Tried other version of btrfsprogs?

 *Quote:*   

> @genstorm

 

Still experimental because fs in the kernel module or state is stable on gentoo repository?

----------

## toralf

 *stephan-t wrote:*   

> And really no leftover space in your drive?

 There are just 420 GB of 2.8 TB are used at that disk. And starting the 4 tinderbox chroot images again few hours later works flawlessly.

----------

## toralf

gah - PEBKAC.

----------

## masc

 *genstorm wrote:*   

> Experimental fs is experimental.

 

it's not marked experimental in 4.x.

running multiple systems on btrfs for a year now and haven't had a single issue yet.

free space can be more complicated to manage, though. the following links may help.

https://btrfs.wiki.kernel.org/index.php/FAQ#Help.21_I_ran_out_of_disk_space.21

http://dustymabe.com/2013/09/22/btrfs-how-big-are-my-snapshots/

----------

## kernelOfTruth

Toralf,

you might want to take a look at Zhao Lei's fix-no-space patchset,

though meanwhile some patches might not apply cleanly anymore

----------

## krinn

from the very start, btrfs has get fix for free space...

it is still not fix  :Wink: 

that's a design flow, it may one day be fix, but at the prize of the original design totally broke down. So once btrfs will be fix for real, the so-called btrfs performances improvements would be dead, hence why they keep adding other functionalities to balance that, as soon as btrfs perfs are no more than just or as bad as other fs, they will argue about features...

----------

