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");}
--
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
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/sda3You 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.
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");} -- 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 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 -- 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
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.htmlLeonidas -- Caution: breathing may be hazardous to your health. #include <stdio.h> int main(){printf("%s","\x4c\x65\x6f\x6e\x69\x64\x61\x73");} -- 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 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 -- 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
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
--
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
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 balanceYou 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...
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...-- 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
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");} -- 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