-musage=>0 means always reporting relocation

-musage=>0 means always reporting relocation

[Russell Coker]

Below is the output of running a balance a few times on a 120G SSD.

It seems that whenever I set the metadata usage to be greater than 0 it will 
report relocating something, regardless of whether that's possible.

root@server:~# btrfs fi balance start -dusage=0 -musage=0 /
Done, had to relocate 0 out of 108 chunks
root@server:~# btrfs fi balance start -dusage=0 -musage=0 /
Done, had to relocate 0 out of 108 chunks
root@server:~# btrfs fi balance start -dusage=0 -musage=10 /
Done, had to relocate 1 out of 108 chunks
root@server:~# btrfs fi balance start -dusage=0 -musage=10 /
Done, had to relocate 1 out of 108 chunks
root@server:~# btrfs fi balance start -dusage=0 -musage=10 /
Done, had to relocate 1 out of 108 chunks
root@server:~# btrfs fi balance start -dusage=0 -musage=10 /
Done, had to relocate 1 out of 108 chunks
root@server:~# btrfs fi balance start -dusage=0 -musage=1 /
Done, had to relocate 1 out of 108 chunks
root@server:~# btrfs fi balance start -dusage=0 -musage=0 /
Done, had to relocate 0 out of 108 chunks
root@server:~# btrfs fi balance start -dusage=1 -musage=0 /
Done, had to relocate 0 out of 108 chunks
root@server:~# btrfs fi balance start -dusage=10 -musage=0 /
Done, had to relocate 0 out of 108 chunks

During each run of -musage=N I'd get a couple of kernel lines like the 
following.  It was apparently doing something, but whatever that was probably 
wasn't useful.

[1394107.479342] BTRFS info (device dm-0): relocating block group 766120755200 
flags 34
[1394107.589661] BTRFS info (device dm-0): found 2 extents

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

Re: -musage=>0 means always reporting relocation

[Russell Coker]

On Sun, 11 May 2014, Russell Coker <russell@coker.com.au> wrote:
> Below is the output of running a balance a few times on a 120G SSD.

Sorry forgot to mention that's kernel 3.14.1 Debian package.

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

Re: -musage=>0 means always reporting relocation

[Brendan Hide]

On 2014/05/11 11:52 AM, Russell Coker wrote:
> On Sun, 11 May 2014, Russell Coker <russell@coker.com.au> wrote:
>> Below is the output of running a balance a few times on a 120G SSD.
> Sorry forgot to mention that's kernel 3.14.1 Debian package.
>
Please send the output of the two following command:
btrfs fi df /

This will give more information on your current chunk situation. I 
suspect this is a case where a system chunk (which is included when 
specifying metadata) that is not actually being relocated. This is a bug 
that I believe was already fixed, though I'm not sure in which version.

The pathological case is where you have a chunk that is 1% full and 
*every* other in-use chunk on the device is 100% full. In that 
situation, a balance will simply move that data into a new chunk (which 
will only ever reach 1% full). Thus, all subsequent balances will 
relocate that same data again to another new chunk.

-- 
__________
Brendan Hide
http://swiftspirit.co.za/
http://www.webafrica.co.za/?AFF1E97

Re: -musage=>0 means always reporting relocation

[Duncan]

Russell Coker posted on Sun, 11 May 2014 19:43:16 +1000 as excerpted:

> Below is the output of running a balance a few times on a 120G SSD.
> 
> It seems that whenever I set the metadata usage to be greater than 0 it
> will report relocating something, regardless of whether that's possible.

Why would it be impossible?  It's certainly not impossible from the 
information posted.

As Brendan suggests, depending on the amount of metadata present, it's 
entirely possible that you have enough to fill X whole metadata chunks, 
plus under 10% and possibly under 1% of the next chunk, such that 
repeatedly running -musage=10 or -musage=1 will repeatedly balance that 
last chunk.

Also, not being a dev I don't normally read code to know whether this is 
an issue or not, but given that btrfs will inline small enough files in 
the metadata, it's theoretically possible that a balanced state where 
more than one metadata chunk remains less than 100% full, if the inlined 
file data doesn't line up to exact chunks.

Then of course there's the dup or raid1 metadata case (dup being the 
normal single-device metadata default, except if ssd is detected, raid1 
being the multi-device metadata default in all cases), such that all 
metadata chunks are duplicated, effectively doubling the number of chunks 
rebalanced since each one has two copies.

-- 
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: -musage=>0 means always reporting relocation

[David Sterba]

On Sun, May 11, 2014 at 04:11:56PM +0200, Brendan Hide wrote:
> On 2014/05/11 11:52 AM, Russell Coker wrote:
> >On Sun, 11 May 2014, Russell Coker <russell@coker.com.au> wrote:
> >>Below is the output of running a balance a few times on a 120G SSD.
> >Sorry forgot to mention that's kernel 3.14.1 Debian package.
> >
> Please send the output of the two following command:
> btrfs fi df /
> 
> This will give more information on your current chunk situation. I suspect
> this is a case where a system chunk (which is included when specifying
> metadata) that is not actually being relocated. This is a bug that I believe
> was already fixed, though I'm not sure in which version.
> 
> The pathological case is where you have a chunk that is 1% full and *every*
> other in-use chunk on the device is 100% full. In that situation, a balance
> will simply move that data into a new chunk (which will only ever reach 1%
> full). Thus, all subsequent balances will relocate that same data again to
> another new chunk.

You're right about the system chunk, the message says it's blockgroup
type '34', which matches SYSTEM (2) and DUP (32).

Seems that the usage value does not propagate to the system group filter
and just processes all its chunks each time, though all the metadata
chunks are correctly filtered.

Re: -musage=>0 means always reporting relocation

[Russell Coker]

On Sun, 11 May 2014 16:11:56 Brendan Hide wrote:
> On 2014/05/11 11:52 AM, Russell Coker wrote:
> > On Sun, 11 May 2014, Russell Coker <russell@coker.com.au> wrote:
> >> Below is the output of running a balance a few times on a 120G SSD.
> > 
> > Sorry forgot to mention that's kernel 3.14.1 Debian package.
> 
> Please send the output of the two following command:
> btrfs fi df /

#btrfs fi balance start -dusage=0 -musage=10 /
Done, had to relocate 2 out of 107 chunks
#btrfs fi balance start -dusage=0 -musage=10 /
Done, had to relocate 2 out of 107 chunks
#btrfs fi balance start -dusage=0 -musage=0 /
Done, had to relocate 1 out of 107 chunks
#btrfs fi balance start -dusage=0 -musage=0 /
Done, had to relocate 1 out of 107 chunks
#btrfs fi balance start -dusage=10 -musage=10 /
Done, had to relocate 2 out of 107 chunks
#btrfs fi balance start -dusage=10 -musage=10 /
Done, had to relocate 2 out of 107 chunks
#btrfs fi balance start -dusage=0 -musage=0 /
Done, had to relocate 1 out of 107 chunks
#btrfs fi balance start -dusage=0 -musage=0 /
Done, had to relocate 1 out of 107 chunks
#btrfs fi df /
Data, single: total=100.47GiB, used=92.11GiB
System, DUP: total=32.00MiB, used=20.00KiB
Metadata, DUP: total=2.50GiB, used=1.50GiB
#uname -a
Linux workstation 3.14-1-amd64 #1 SMP Debian 3.14.2-1 (2014-04-28) x86_64 
GNU/Linux

Above is my workstation.  Below is the server/workstation my wife uses.

#btrfs fi balance start -dusage=0 -musage=0 / 
Done, had to relocate 0 out of 81 chunks
#btrfs fi balance start -dusage=0 -musage=0 / 
Done, had to relocate 0 out of 81 chunks
#btrfs fi balance start -dusage=1 -musage=1 / 
Done, had to relocate 1 out of 81 chunks
#btrfs fi balance start -dusage=1 -musage=1 / 
Done, had to relocate 1 out of 81 chunks
#btrfs fi balance start -dusage=1 -musage=1 / 
Done, had to relocate 1 out of 81 chunks
#btrfs fi balance start -dusage=0 -musage=0 / 
Done, had to relocate 0 out of 81 chunks
#btrfs fi df /
Data: total=75.01GB, used=52.32GB
System, DUP: total=32.00MB, used=16.00KB
Metadata, DUP: total=2.50GB, used=1.52GB
#uname -a
Linux server 3.14-trunk-amd64 #1 SMP Debian 3.14.1-1~exp1 (2014-04-17) x86_64 
GNU/Linux

> This will give more information on your current chunk situation. I
> suspect this is a case where a system chunk (which is included when
> specifying metadata) that is not actually being relocated. This is a bug
> that I believe was already fixed, though I'm not sure in which version.
> 
> The pathological case is where you have a chunk that is 1% full and
> *every* other in-use chunk on the device is 100% full. In that
> situation, a balance will simply move that data into a new chunk (which
> will only ever reach 1% full). Thus, all subsequent balances will
> relocate that same data again to another new chunk.

In that pathological case surely the correct thing to do is to not move that 
chunk.  If moving a chunk doesn't achieve filesystem tuning goals (EG 
converting to a different RAID level) and doesn't result in a decrease of the 
number of chunks in use then surely there's no point to doing it.

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

Re: -musage=>0 means always reporting relocation

[Duncan]

Russell Coker posted on Tue, 13 May 2014 17:57:00 +1000 as excerpted:

>> The pathological case is where you have a chunk that is 1% full and
>> *every* other in-use chunk on the device is 100% full. In that
>> situation, a balance will simply move that data into a new chunk (which
>> will only ever reach 1% full). Thus, all subsequent balances will
>> relocate that same data again to another new chunk.
> 
> In that pathological case surely the correct thing to do is to not move
> that chunk.  If moving a chunk doesn't achieve filesystem tuning goals
> (EG converting to a different RAID level) and doesn't result in a
> decrease of the number of chunks in use then surely there's no point to
> doing it.

But what balance and the resulting multi-chunk interactions does is 
complex enough, that in general it doesn't know whether it's going to 
decrease the number of chunks used until it actually goes thru the 
motions and tries it.  In theory, a "dry-run" option could be added, but 
it would still take near the same amount of time as it has to check the 
same stuff, just not do the rewrite, and potentially, tracking the dry-
run results would increase memory usage significantly.

Meanwhile, what if an admin is wanting to simply rewrite the data, to 
check the filesystem validity and renew the on-media signal strength to 
avoid bit-rot, defragging in the process?  That's a valid balance use-
case as that's what it actually does.

Someone mentioned trying to use scrub to check filesystem validity, and I 
said that was the wrong tool for the job as all it did was validate 
checksums; it didn't validate internal structure.  But balance obviously 
must validate that internal structure as well as checksums, as it's 
actually reading and rewriting, potentially the entire filesystem, as it 
goes.

So I'd say the correct thing to do *IS* to rewrite that chunk, because 
that's what balance *DOES*.  That it happens to consolidate chunks as it 
goes is one effect, certainly a good one, but it's not the only effect, 
and not rewriting chunks simply because there would be no consolidation 
would both seriously complexify things, and ignore the other reasons one 
might be running the balance.

-- 
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