btrfs balance on single device

btrfs balance on single device

[Leonidas Spyropoulos]

Hey all,

Just did a btrfs balance on a single device. Before the balance
operation here is the df result:

inglor@tiamat ~$ btrfs fi df /home
Data: total=19.19GB, used=9.34GB
System, DUP: total=32.00MB, used=4.00KB
Metadata, DUP: total=896.00MB, used=227.98MB

Then I issues a balance operation relocating the chunks across a single device:
inglor@tiamat ~$ sudo btrfs fi balance /home
[sudo] password for inglor:
Done, had to relocate 28 out of 28 chunks

After I did another df:
inglor@tiamat ~$ btrfs fi df /home
Data: total=10.00GB, used=9.34GB
System, DUP: total=32.00MB, used=4.00KB
Metadata, DUP: total=384.00MB, used=226.80MB

Anyone can explain me the Data row of the above output ? It used to be
19.19GB and now it's 10.00GB. It's like the partition shrunk!? The
balance operation finished without issues.

Here's some other information:

inglor@tiamat ~$ sudo btrfs filesystem show
Label: 'home'  uuid: 458c70e2-7037-4c4d-bba2-3d5288f04510
    Total devices 1 FS bytes used 9.56GB
    devid    1 size 21.00GB used 10.81GB path /dev/sda3

Label: none  uuid: 699d671b-7064-441d-95ec-c616049fe287
    Total devices 1 FS bytes used 13.94GB
    devid    1 size 20.00GB used 20.00GB path /dev/sda2

Btrfs v0.20-rc1-358-g194aa4a-dirty
inglor@tiamat ~$ df
Filesystem     1K-blocks      Used Available Use% Mounted on
/dev/sda2       20971520  15362816   3960288  80% /
/dev/sda3       22020096  10256168  11375416  48% /home

Thanks,
Leonidas


-- 
Caution: breathing may be hazardous to your health.

#include <stdio.h>
int main(){printf("%s","\x4c\x65\x6f\x6e\x69\x64\x61\x73");}

Re: btrfs balance on single device

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 2204 bytes --]

On Sun, Dec 15, 2013 at 08:20:19PM +0000, Leonidas Spyropoulos wrote:
> Hey all,
> 
> Just did a btrfs balance on a single device. Before the balance
> operation here is the df result:
> 
> inglor@tiamat ~$ btrfs fi df /home
> Data: total=19.19GB, used=9.34GB
> System, DUP: total=32.00MB, used=4.00KB
> Metadata, DUP: total=896.00MB, used=227.98MB
> 
> Then I issues a balance operation relocating the chunks across a single device:
> inglor@tiamat ~$ sudo btrfs fi balance /home
> [sudo] password for inglor:
> Done, had to relocate 28 out of 28 chunks
> 
> After I did another df:
> inglor@tiamat ~$ btrfs fi df /home
> Data: total=10.00GB, used=9.34GB
> System, DUP: total=32.00MB, used=4.00KB
> Metadata, DUP: total=384.00MB, used=226.80MB
> 
> Anyone can explain me the Data row of the above output ? It used to be
> 19.19GB and now it's 10.00GB. It's like the partition shrunk!? The
> balance operation finished without issues.

   It freed up some of the unused data chunks, returning them to the
unallocated space on the device.

> Here's some other information:
> 
> inglor@tiamat ~$ sudo btrfs filesystem show
> Label: 'home'  uuid: 458c70e2-7037-4c4d-bba2-3d5288f04510
>     Total devices 1 FS bytes used 9.56GB
>     devid    1 size 21.00GB used 10.81GB path /dev/sda3

   You can see that the filesystem is still the same size as before --
it's just that less of it is allocated.

   There's nothing to worry about here -- it's all working as expected.

   Hugo.

> Label: none  uuid: 699d671b-7064-441d-95ec-c616049fe287
>     Total devices 1 FS bytes used 13.94GB
>     devid    1 size 20.00GB used 20.00GB path /dev/sda2
> 
> Btrfs v0.20-rc1-358-g194aa4a-dirty
> inglor@tiamat ~$ df
> Filesystem     1K-blocks      Used Available Use% Mounted on
> /dev/sda2       20971520  15362816   3960288  80% /
> /dev/sda3       22020096  10256168  11375416  48% /home
> 
> Thanks,
> Leonidas
> 
> 

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
         --- If you're not part of the solution, you're part ---         
                           of the precipiate.                            

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: btrfs balance on single device

[Leonidas Spyropoulos]

On Sun, Dec 15, 2013 at 8:24 PM, Hugo Mills <hugo@carfax.org.uk> wrote:
> On Sun, Dec 15, 2013 at 08:20:19PM +0000, Leonidas Spyropoulos wrote:
>> Hey all,
[..]
>> Anyone can explain me the Data row of the above output ? It used to be
>> 19.19GB and now it's 10.00GB. It's like the partition shrunk!? The
>> balance operation finished without issues.
>
>    It freed up some of the unused data chunks, returning them to the
> unallocated space on the device.
>
Oh, so the df report from btrfs doesn't show the total as 'free'! But
it means how much space the filesystem allocated so far.
>> Here's some other information:
>>
>> inglor@tiamat ~$ sudo btrfs filesystem show
>> Label: 'home'  uuid: 458c70e2-7037-4c4d-bba2-3d5288f04510
>>     Total devices 1 FS bytes used 9.56GB
>>     devid    1 size 21.00GB used 10.81GB path /dev/sda3
>
>    You can see that the filesystem is still the same size as before --
> it's just that less of it is allocated.
>
>    There's nothing to worry about here -- it's all working as expected.
>
>    Hugo.
>

Thanks Hugo for the explanation

Leonidas

-- 
Caution: breathing may be hazardous to your health.

#include <stdio.h>
int main(){printf("%s","\x4c\x65\x6f\x6e\x69\x64\x61\x73");}

Re: btrfs balance on single device

[Duncan]

Leonidas Spyropoulos posted on Sun, 15 Dec 2013 20:28:05 +0000 as
excerpted:

> Oh, so the df report from btrfs doesn't show the total as 'free'! But it
> means how much space the filesystem allocated so far.

Yes.

Btrfs allocates in chunks, 256 MiB at a time for metadata (but on a 
single device, metadata chunks are DUP by default, so two are created at 
once, thus half a gig), 1 GiB at at a time for data (single device 
values, when there's plenty of unallocated space left in ordered to do 
so).  As these chunks are filled up new ones are allocated as necessary 
(assuming there's enough unallocated space left to do so).

But normal usage including deleting old files and rewriting parts of 
existing files (to new locations due to btrfs' copy-on-write/COW 
semantics) will often leave several partially filled chunks around, and a 
balance rewrites chunks, consolidating into fewer new chunks when 
possible as it does so.

That's what the btrfs fi df reports showed, many partially filled chunks 
before the balance, fewer but full chunks afterward, with the freed chunk 
space returned to the unallocated pool.

While btrfs fi df could report unallocated space as well, given the 
possibility of it being allocated differently (DUP vs SINGLE, and on 
multi-device filesystems, the various raid modes), it can't reliably 
predict how that unallocated space will be used and thus how much 
/effective/ free space you have.

But btrfs fi show gives the total filesystem size, as well as the total 
allocated.  So between df and show, plus a little math if necessary, you 
get a better picture.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: btrfs balance on single device

[Leonidas Spyropoulos]

On Sun, Dec 15, 2013 at 11:28 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> Leonidas Spyropoulos posted on Sun, 15 Dec 2013 20:28:05 +0000 as
> excerpted:
>
>> Oh, so the df report from btrfs doesn't show the total as 'free'! But it
>> means how much space the filesystem allocated so far.
>
> Yes.
>
> Btrfs allocates in chunks, 256 MiB at a time for metadata (but on a
> single device, metadata chunks are DUP by default, so two are created at
> once, thus half a gig), 1 GiB at at a time for data (single device
> values, when there's plenty of unallocated space left in ordered to do
> so).  As these chunks are filled up new ones are allocated as necessary
> (assuming there's enough unallocated space left to do so).
>
> But normal usage including deleting old files and rewriting parts of
> existing files (to new locations due to btrfs' copy-on-write/COW
> semantics) will often leave several partially filled chunks around, and a
> balance rewrites chunks, consolidating into fewer new chunks when
> possible as it does so.
>
> That's what the btrfs fi df reports showed, many partially filled chunks
> before the balance, fewer but full chunks afterward, with the freed chunk
> space returned to the unallocated pool.
>
> While btrfs fi df could report unallocated space as well, given the
> possibility of it being allocated differently (DUP vs SINGLE, and on
> multi-device filesystems, the various raid modes), it can't reliably
> predict how that unallocated space will be used and thus how much
> /effective/ free space you have.
>
> But btrfs fi show gives the total filesystem size, as well as the total
> allocated.  So between df and show, plus a little math if necessary, you
> get a better picture.

But on the time that someone invokes the "btrfs fi df" command all the
informations are available on the underlying driver to determine the
type of allocation (DUP or SINGLE) and if the volume is single or multi
device. So is there a reason not to do the maths for the user and
present her/him with the correct information, saving her/his braincells
from maths? :)

I assume there's performance degragation from having all the chunks
allocated in a volume. Is there a recomendation on how often once should
run the balance operation? If on the other hand no performance is
decreased from having all the chunks allocated why not allocate them on
the start (creation of filesystem / mount - not sure which is
appropriate).

>
> --
> Duncan - List replies preferred.   No HTML msgs.
> "Every nonfree program has a lord, a master --
> and if you use the program, he is your master."  Richard Stallman
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


Leonidas
-- 
Caution: breathing may be hazardous to your health.

#include <stdio.h>
int main(){printf("%s","\x4c\x65\x6f\x6e\x69\x64\x61\x73");}

Re: btrfs balance on single device

[Duncan]

Leonidas Spyropoulos posted on Mon, 16 Dec 2013 23:22:54 +0000 as
excerpted:

> I assume there's performance degragation from having all the chunks
> allocated in a volume. Is there a recomendation on how often once should
> run the balance operation? If on the other hand no performance is
> decreased from having all the chunks allocated why not allocate them on
> the start (creation of filesystem / mount - not sure which is
> appropriate).

I don't know that there's performance degradation, but it'd be a loss of 
flexibility, for sure.

Unallocated space can be allocated to either data or metadata chunks as 
the need arises.  Set them all up at the beginning and you're locking 
yourself into a particular ratio that's likely to be wrong -- you'll 
likely run out of one while you have whole empty chunks of the other one 
just sitting there, useless!

Additionally, while currently btrfs has a single allocation policy in 
effect at a given moment, it's possible to convert between single and dup 
metadata on a single device, and once multiple devices are involved, 
there's the various raid choices for both data and metadata, as well as 
single/dup modes.  If the allocation policy has changed, it's possible 
for some chunks to be allocated using one policy, while others are 
allocated using a different policy, and while it's not supported yet, the 
roadmap calls for per-subvolume allocation policy as well, and once that 
occurs, how that free space will be allocated will depend on which 
subvolume its allocated to and the allocation policy for that subvolume 
at the time.

Pre-allocate all chunks and you lose that flexibility entirely.

Finally, a balance is used to rewrite chunks, consolidating partially 
used chunks into one where possible, and reallocating based on current 
allocation policy.  But in ordered for a balance to work, there must be 
at least enough unallocated space for it to allocate at least one new 
chunk in ordered to transfer the content of one old chunk at a time to 
the new one.  Allocate all your chunks at the beginning, and balance 
won't have that free space available in ordered to allocate a new one and 
do those rewrites, thus locking out your ability to consolidate partially 
used chunks for better efficiency as well as possible conversion. =:^(


As for how often to run balance, that depends entirely on your use-case.  
On spinning-rust, balancing a large multi-terabyte filesystem can take 
hours or even days, so it's not something you'd probably want to do so 
often.  On SSDs and with smaller filesystems, the time will of course be 
shorter (a balance on my largest btrfs here, 24 gig on fast SSD, only 
takes about five minutes, with my smaller filesystems completing a 
balance in a few seconds to a couple minutes), so much so that running a 
balance is trivial in terms of time, but of course SSDs are limited write-
cycle, and needlessly rebalancing costs write-cycles.

Meanwhile, a nearly full filesystem will have most or all its chunks 
allocated, and they're not automatically deallocated.  It's thus a good 
idea to run a balance after deleting a lot of files, thus freeing up the 
allocations and returning the space to the flexible-use unallocated 
pool.  And a balance is the method used to re-balance (thus the name) 
allocations between devices after adding or removing devices, and to 
convert between single/dup/raidN modes if your allocation policy changes.

Generally, in the absence of a conversion or device add/remove run, I run 
a balance whenever btrfs fi df shows a multi-chunk difference between 
what's allocated and what's actually used, again, based on a metadata 
chunk size of a quarter GiB (tho btrfs defaults to DUP mode on a single 
device so it'll allocate two at once), with a data chunk size of 1 GiB.  
But if I ran much larger btrfs with hundreds of gigs free, I'd probably 
wait until I was down to a few gigs free to run the balance, since it'd 
likely be a multi-hour or even multi-day process on spinning rust, and on 
SSD it'd be faster, but would as I said unnecessarily use up limited 
write-cycles.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: btrfs balance on single device

[Leonidas Spyropoulos]

I'm using the same subject as it might be relevant, feel free to change it.#

I'm trying to do some maintenance to the system running over a btrfs file system on root (/). I started a balance on the '/' partition and it failed with the below information:
$ sudo btrfs balance start /
[sudo] password for inglor:
ERROR: error during balancing '/' - No space left on device
There may be more info in syslog - try dmesg | tail
$ dmesg | tail
[93827.115887] btrfs: found 29461 extents
[93827.481849] btrfs: relocating block group 29855055872 flags 1
[93841.646011] btrfs: found 33171 extents
[93851.421207] btrfs: found 33171 extents
[93851.782054] btrfs: relocating block group 28781314048 flags 1
[93866.815342] btrfs: found 52535 extents
[93877.159354] btrfs: found 52534 extents
[93877.356805] btrfs: relocating block group 28747759616 flags 34
[93880.287185] btrfs: found 1 extents
[93880.608798] btrfs: 1 enospc errors during balance

$ df |grep sda2
/dev/sda2       20971520  13980396   5797124  71% /


$ sudo btrfs fi show
[sudo] password for inglor:
Label: none  uuid: 699d671b-7064-441d-95ec-c616049fe287
        Total devices 1 FS bytes used 12.75GB
        devid    1 size 20.00GB used 15.31GB path /dev/sda2

Btrfs v0.20-rc1-358-g194aa4a-dirty

$ sudo btrfs fi df /
[sudo] password for inglor:
Data: total=13.00GB, used=12.16GB
System, DUP: total=32.00MB, used=4.00KB
Metadata, DUP: total=1.12GB, used=601.54MB

Does it really needs more than 5.7GB to do a balance? I though it suppose to move chunks one by one and considering the chunks for Data is 1GB and for MetaData 512MB (256 x2 for dublication) it should be more than enough.
Also I had less space before and the dmesg reported 7 enospc errors. With cleaning a bit of packages installed now it reports only 1 enospc. Is that anywhere relevant?

Thanks,
Leonidas

Re: btrfs balance on single device

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 3136 bytes --]

On Wed, Dec 18, 2013 at 10:44:43AM +0000, Leonidas Spyropoulos wrote:
> I'm using the same subject as it might be relevant, feel free to change it.#
> 
> I'm trying to do some maintenance to the system running over a btrfs file system on root (/). I started a balance on the '/' partition and it failed with the below information:
> $ sudo btrfs balance start /
> [sudo] password for inglor:
> ERROR: error during balancing '/' - No space left on device
> There may be more info in syslog - try dmesg | tail
> $ dmesg | tail
> [93827.115887] btrfs: found 29461 extents
> [93827.481849] btrfs: relocating block group 29855055872 flags 1
> [93841.646011] btrfs: found 33171 extents
> [93851.421207] btrfs: found 33171 extents
> [93851.782054] btrfs: relocating block group 28781314048 flags 1
> [93866.815342] btrfs: found 52535 extents
> [93877.159354] btrfs: found 52534 extents
> [93877.356805] btrfs: relocating block group 28747759616 flags 34
> [93880.287185] btrfs: found 1 extents
> [93880.608798] btrfs: 1 enospc errors during balance

   You don't specify your kernel version, but if it's older than 3.11
or so, you should probably upgrade -- 3.10 and earlier had occasional
bugs where the block reserve system never kept enough blocks free to
add a new metadata chunk when it was needed, which led to exactly this
kind of symptom.

   Alternatively, and this is a bit of a long shot given that the
error seems to have been while relocating your system chunk (which
argues against this particular diagnosis), but:

   Do you have a large file on that filesystem (larger than 1 GiB)?

   If so, I would recommend switching to a 3.12 kernel, and running a
defrag on the file. There's a known and now-fixed bug where you can
get ENOSPC while balancing, if a file has an extent larger than 1 GiB
in size. (The bug being that there's an extent over 1 GiB in size in
the first place).

   Hugo.

> $ df |grep sda2
> /dev/sda2       20971520  13980396   5797124  71% /
> 
> 
> $ sudo btrfs fi show
> [sudo] password for inglor:
> Label: none  uuid: 699d671b-7064-441d-95ec-c616049fe287
>         Total devices 1 FS bytes used 12.75GB
>         devid    1 size 20.00GB used 15.31GB path /dev/sda2
> 
> Btrfs v0.20-rc1-358-g194aa4a-dirty
> 
> $ sudo btrfs fi df /
> [sudo] password for inglor:
> Data: total=13.00GB, used=12.16GB
> System, DUP: total=32.00MB, used=4.00KB
> Metadata, DUP: total=1.12GB, used=601.54MB
> 
> Does it really needs more than 5.7GB to do a balance? I though it suppose to move chunks one by one and considering the chunks for Data is 1GB and for MetaData 512MB (256 x2 for dublication) it should be more than enough.
> Also I had less space before and the dmesg reported 7 enospc errors. With cleaning a bit of packages installed now it reports only 1 enospc. Is that anywhere relevant?
> 
> Thanks,
> Leonidas

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
         --- I'd make a joke about UDP,  but I don't know if ---         
                     anyone's actually listening...                      

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: btrfs balance on single device

[Leonidas Spyropoulos]

On Wed, Dec 18, 2013 at 11:05:29AM +0000, Hugo Mills wrote:
> On Wed, Dec 18, 2013 at 10:44:43AM +0000, Leonidas Spyropoulos wrote:
> > I'm using the same subject as it might be relevant, feel free to change it.#
> > 
> > I'm trying to do some maintenance to the system running over a btrfs file system on root (/). I started a balance on the '/' partition and it failed with the below information:
> > $ sudo btrfs balance start /
> > [sudo] password for inglor:
> > ERROR: error during balancing '/' - No space left on device
> > There may be more info in syslog - try dmesg | tail
> > $ dmesg | tail
> > [93827.115887] btrfs: found 29461 extents
> > [93827.481849] btrfs: relocating block group 29855055872 flags 1
> > [93841.646011] btrfs: found 33171 extents
> > [93851.421207] btrfs: found 33171 extents
> > [93851.782054] btrfs: relocating block group 28781314048 flags 1
> > [93866.815342] btrfs: found 52535 extents
> > [93877.159354] btrfs: found 52534 extents
> > [93877.356805] btrfs: relocating block group 28747759616 flags 34
> > [93880.287185] btrfs: found 1 extents
> > [93880.608798] btrfs: 1 enospc errors during balance
> 
>    You don't specify your kernel version, but if it's older than 3.11
> or so, you should probably upgrade -- 3.10 and earlier had occasional
> bugs where the block reserve system never kept enough blocks free to
> add a new metadata chunk when it was needed, which led to exactly this
> kind of symptom.

You are right, apologies. It is an up to date Archlinux box with a kernel:
$ uname -a
Linux tiamat 3.12.5-1-ARCH #1 SMP PREEMPT Thu Dec 12 12:57:31 CET 2013 x86_64 GNU/Linux

> 
>    Alternatively, and this is a bit of a long shot given that the
> error seems to have been while relocating your system chunk (which
> argues against this particular diagnosis), but:
> 
>    Do you have a large file on that filesystem (larger than 1 GiB)?

Unlikely since the btrfs file system in question is '/' exluding /opt and /media directories (these are other partitions)
$ sudo find / -type f -size +1048576k -and -not -path "/media*" -print
/proc/kcore
find: `/proc/27221/task/27221/fd/5': No such file or directory
find: `/proc/27221/task/27221/fdinfo/5': No such file or directory
find: `/proc/27221/fd/5': No such file or directory
find: `/proc/27221/fdinfo/5': No such file or directory
find: `/run/user/1000/gvfs': Permission denied
inglor@tiamat ~$

> 
>    If so, I would recommend switching to a 3.12 kernel, and running a
> defrag on the file. There's a known and now-fixed bug where you can
> get ENOSPC while balancing, if a file has an extent larger than 1 GiB
> in size. (The bug being that there's an extent over 1 GiB in size in
> the first place).

I might try the defrag option anyway and restart the balance operation, see if this will help anyway.

Thanks,
Leonidas

> 
>    Hugo.
> 
> -- 
> === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
>   PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
>          --- I'd make a joke about UDP,  but I don't know if ---         
>                      anyone's actually listening...                      

Re: btrfs balance on single device

[Leonidas Spyropoulos]

On Wed, Dec 18, 2013 at 11:29 AM, Leonidas Spyropoulos
<artafinde@gmail.com> wrote:
> On Wed, Dec 18, 2013 at 11:05:29AM +0000, Hugo Mills wrote:
>> On Wed, Dec 18, 2013 at 10:44:43AM +0000, Leonidas Spyropoulos wrote:
>> > I'm using the same subject as it might be relevant, feel free to change it.#
>> >
>> > I'm trying to do some maintenance to the system running over a btrfs file system on root (/). I started a balance on the '/' partition and it failed with the below information:
>> > $ sudo btrfs balance start /
>> > [sudo] password for inglor:
>> > ERROR: error during balancing '/' - No space left on device
>> > There may be more info in syslog - try dmesg | tail
>> > $ dmesg | tail
>> > [93827.115887] btrfs: found 29461 extents
>> > [93827.481849] btrfs: relocating block group 29855055872 flags 1
>> > [93841.646011] btrfs: found 33171 extents
>> > [93851.421207] btrfs: found 33171 extents
>> > [93851.782054] btrfs: relocating block group 28781314048 flags 1
>> > [93866.815342] btrfs: found 52535 extents
>> > [93877.159354] btrfs: found 52534 extents
>> > [93877.356805] btrfs: relocating block group 28747759616 flags 34
>> > [93880.287185] btrfs: found 1 extents
>> > [93880.608798] btrfs: 1 enospc errors during balance
>>
>>    You don't specify your kernel version, but if it's older than 3.11
>> or so, you should probably upgrade -- 3.10 and earlier had occasional
>> bugs where the block reserve system never kept enough blocks free to
>> add a new metadata chunk when it was needed, which led to exactly this
>> kind of symptom.
>
> You are right, apologies. It is an up to date Archlinux box with a kernel:
> $ uname -a
> Linux tiamat 3.12.5-1-ARCH #1 SMP PREEMPT Thu Dec 12 12:57:31 CET 2013 x86_64 GNU/Linux
>
>>
>>    Alternatively, and this is a bit of a long shot given that the
>> error seems to have been while relocating your system chunk (which
>> argues against this particular diagnosis), but:
>>
>>    Do you have a large file on that filesystem (larger than 1 GiB)?
>
> Unlikely since the btrfs file system in question is '/' exluding /opt and /media directories (these are other partitions)
> $ sudo find / -type f -size +1048576k -and -not -path "/media*" -print
> /proc/kcore
> find: `/proc/27221/task/27221/fd/5': No such file or directory
> find: `/proc/27221/task/27221/fdinfo/5': No such file or directory
> find: `/proc/27221/fd/5': No such file or directory
> find: `/proc/27221/fdinfo/5': No such file or directory
> find: `/run/user/1000/gvfs': Permission denied
> inglor@tiamat ~$
>
>>
>>    If so, I would recommend switching to a 3.12 kernel, and running a
>> defrag on the file. There's a known and now-fixed bug where you can
>> get ENOSPC while balancing, if a file has an extent larger than 1 GiB
>> in size. (The bug being that there's an extent over 1 GiB in size in
>> the first place).
>
> I might try the defrag option anyway and restart the balance operation, see if this will help anyway.

Some progress on this. I managed to do a balance on data only. The
problem seems to be happening when doing a metadata balance

$ sudo btrfs balance start -m /
[sudo] password for inglor:
ERROR: error during balancing '/' - No space left on device
There may be more info in syslog - try dmesg | tail
$ dmesg | tail
[171492.384314] systemd-journald[183]: Deleted empty journal
/var/log/journal/64cfb6f6c9d1625e7fa463c200000475/user-120@8b61bc353813451babcaa25dfc82c64e-0000000000000000-0000000000000000.journal
(2924544 bytes).
[171492.384375] systemd-journald[183]: Vacuuming done, freed 2924544 bytes
[172242.011051] btrfs: relocating block group 109781712896 flags 36
[172242.075298] btrfs: relocating block group 109748158464 flags 34
[172242.286016] btrfs: found 1 extents
[172242.419286] btrfs: 1 enospc errors during balance

Is there a way to recreate the metadata? (I'm guessing the answer is balance..)

>
> Thanks,
> Leonidas
>
>>
>>    Hugo.
>>
>> --
>> === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
>>   PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
>>          --- I'd make a joke about UDP,  but I don't know if ---
>>                      anyone's actually listening...



-- 
Caution: breathing may be hazardous to your health.

#include <stdio.h>
int main(){printf("%s","\x4c\x65\x6f\x6e\x69\x64\x61\x73");}