how long should btrfs fi balance take?

how long should btrfs fi balance take?

[Russell Coker]

# btrfs filesystem df /
Data: total=101.57GB, used=75.75GB
System, DUP: total=8.00MB, used=24.00KB
System: total=4.00MB, used=0.00
Metadata, DUP: total=3.00GB, used=2.09GB
Metadata: total=8.00MB, used=0.00
# btrfs filesystem df /
Data: total=100.57GB, used=77.00GB
System, DUP: total=8.00MB, used=24.00KB
System: total=4.00MB, used=0.00
Metadata, DUP: total=3.50GB, used=2.35GB
Metadata: total=8.00MB, used=0.00

I've had btrfs filesystem balance running on a partition of my 120G Intel SSD 
for almost 7 hours.  The above two runs of fi df were before the balance and 
after it had run for almost 7 hours.  The system is in operation during this 
process, I've used it for email, web browsing, and I downloaded a movie from 
Youtube.

Also during the process the usual cron jobs have been running including the 
one that makes a snapshot of /home every 15 minutes.

Is it considered to be a bad idea to make snapshots while doing a balance?

Should a balance take so long anyway?  It's been mostly CPU bound an on E4600 
CPU, that's a bit dated but it's still dual-core 64bit and whatever the btrfs 
utility has done to use 327 minutes of CPU time is probably wrong.

Any suggestions on other information I should provide?  I'm using 3.10.7 in 
Debian package linux-image-3.10-2-amd64 version 3.10.7-1 and version 
0.19+20130705-1 of the btrfs-tools in Debian/Unstable.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

Re: how long should btrfs fi balance take?

[Duncan]

Russell Coker posted on Tue, 03 Sep 2013 18:21:35 +1000 as excerpted:

> # btrfs filesystem df /
> Data: total=100.57GB, used=77.00GB
> System, DUP: total=8.00MB, used=24.00KB
> System: total=4.00MB, used=0.00
> Metadata, DUP: total=3.50GB, used=2.35GB
> Metadata: total=8.00MB, used=0.00
> 
> I've had btrfs filesystem balance running on a partition of my 120G
> Intel SSD for almost 7 hours.

> Should a balance take so long anyway?  It's been mostly CPU bound an on
> E4600  CPU, that's a bit dated but it's still dual-core 64bit and
> whatever the btrfs  utility has done to use 327 minutes of CPU time is
> probably wrong.
> 
> Any suggestions on other information I should provide?  I'm using
> 3.10.7 in  Debian package linux-image-3.10-2-amd64 version 3.10.7-1 and
> version 0.19+20130705-1 of the btrfs-tools in Debian/Unstable.

My system's somewhat different, AMD fx6100 six-core, dual Corsair Neutron 
SSDs mostly in btrfs raid1 mode, and I chose to partition my SSDs and run 
multiple independent filesystems rather than putting all my data eggs in 
one still under development btrfs filesystem basket, but it's fairly fast 
SSD and the filesystem times can be scaled for the data involved, so this 
should be relevant:

A timed balance on my /home takes roughly two minutes, with the balance 
saying it relocated 16 out of 16 chunks.  According to btrfs fi df /home:

Data, RAID1: total=13.00GB, used=11.52GB
System, RAID1: total=32.00MB, used=4.00KB
System: total=4.00MB, used=0.00
Metadata, RAID1: total=1.00GB, used=521.69MB

... and btrfs fi sh

Total devices 2 FS bytes used 12.03GB
devid    2 size 20.00GB used 14.03GB path /dev/sda6
devid    1 size 20.00GB used 14.04GB path /dev/sdb6

So it's a 20-gig filesystem with two copies, 13 gig data of which 11.5 is 
used, 1 gig metadata just over half used, about 14 gig total usage.

14 gig relocated in ~2 minutes is ~7 gigs a minute.

You have about 104 gig of data and metadata combined, so to scale it 
should take roughly 15 minutes.  If your SSD is slow or you're only on 
SATA2 instead of the SATA3 I'm on, that might double to half an hour, but 
there's really no reason it should take over an hour on what I know of 
your hardware.

Meanwhile, 3.11 was JUST released, and you're running 3.10.7, so you're 
basically running a current kernel.  Similarly, your btrfs tools are a 
snapshot from early July so they're slightly behind but not bad.

So you're running into a bug.

I'm just a btrfs user but I follow the list, and I'd guess you might be 
running into the chunk looping bug I saw a patch go by on the list for.  
You might try the /just/ released 3.11 and see if it helps.

Meanwhile, I'm running a git kernel, 3.11-rc6-00072-g1f8b766 (3.11-series 
but about two weeks old I guess), and in checking the balance time I 
posted above, my first balance /home segfaulted, and shortly after that, 
various apps quit responding.  I rebooted using magic-srq to sync and 
mount-readonly what was possible before the reboot (and / is mounted read-
only normally, so it wasn't ever in serious danger), and the balance 
completed after the reboot.  I then did another balance without issue -- 
it completed successfully, and I did a scrub to be sure -- no errors to 
fix.  So whatever triggered the balance segfault the first time around 
appears to have disappeared along with the reboot.

I guess I don't know which is worse, a looping balance that eats CPU but 
never completes, or a segfaulting balance that triggers unresponsive apps 
and forces a semi-graceful reboot.

But either way, seven hours for about a hundred gig on what should be a 
reasonably fast SSD, yes, there's definitely something wrong.  I'd reboot 
and see if the balance completes then and/or if you can run a balance in 
reasonable time after the reboot.

-- 
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: how long should btrfs fi balance take?

[Russell Coker]

On Wed, 4 Sep 2013, Duncan <1i5t5.duncan@cox.net> wrote:
> But either way, seven hours for about a hundred gig on what should be a 
> reasonably fast SSD, yes, there's definitely something wrong.  I'd reboot 
> and see if the balance completes then and/or if you can run a balance in 
> reasonable time after the reboot.

Thanks for the suggestion.  I rebooted and then ran a balance again which 
completed in 8 minutes.

Then I attempted another balance without rebooting and it hung again.  Maybe a 
balance after the cron job had created a new snapshot causes the problem.  
I'll have to reboot and try it again.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/