Metadata chunk fragmentation?

[Jeremy Atkins]

I have a 5 drive btrfs pool that seems to be getting slow

If i start/cancel a rebalance on metadata, it will take 15 to 20
minutes to do 1 chunk, then in dmesg i'll see this:

-mconvert=raid5
[Sat Jul 27 22:16:12 2013] btrfs: relocating block group 18228861403136 flags 20
[Sat Jul 27 22:31:53 2013] btrfs: found 86835 extents
-mconvert=raid1,soft
[Sat Jul 27 22:37:02 2013] btrfs: relocating block group
18230102917120 flags 132
[Sat Jul 27 22:58:16 2013] btrfs: found 88595 extents

My main question I wanted to know is, Should I even care about the
large number of extents, because when I converted all of the metadata
from raid10 to raid1, most of the chunks 100k+ extents. If i should
care, is there a way to defragment the actual chunks?

More info about my system:
kernel 3.9.9-301.fc19.x86_64
dual core 2.2ghz, 4gb ram

$ btrfs fi df /
Data, RAID10: total=3.41TB, used=3.10TB
System, RAID1: total=32.00MB, used=396.00KB
Metadata, RAID1: total=6.00GB, used=4.33GB

$ sudo btrfs fi sh
Label: 'btrfs_tank'  uuid: b0ad55e2-09e0-4658-8cab-d2e11ba03753
Total devices 6 FS bytes used 3.10TB
devid8 size 1.36TB used 1.10TB path /dev/sde1
devid2 size 1.81TB used 1.50TB path /dev/sdd4
devid6 size 1.82TB used 1.56TB path /dev/sdc1
devid5 size 1.36TB used 1.11TB path /dev/sdb1
devid7 size 1.82TB used 1.56TB path /dev/sda1
*** Some devices missing

The missing device... is a different cosmetic problem, happened a long
time ago when I had failing drive, added new drive. did did device
remove, rebooted after it finished and then it started saying
missing...
$ sudo btrfs dev delete missing /
$ dmesg |tail -n1
[1662429.066371] btrfs: no missing devices found to remove
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

'filesystem resize max' tries to use devid 1

[Jeremy Atkins]

Back story:
I started my pool with a 200gb partition at the end of my drive (sdc5)
, until I was able to clear out the data at the beginning of my drive.
 When I was ready, I ran `btrfs dev add /dev/sdc4 /` then `btrfs dev
del /dev/sdc5 /`,

$ sudo btrfs fi resize max /
Resize '/' of 'max'
ERROR: unable to resize '/' - Invalid argument

in dmesg i see:
[   72.729685] btrfs: resizer unable to find device 1

$ sudo btrfs fi df /
Data: total=34.00GB, used=17.79GB
System, DUP: total=64.00MB, used=20.00KB
Metadata, DUP: total=33.50GB, used=394.93MB

$ sudo btrfs fi sh
Label: none  uuid: b0ad55e2-09e0-4658-8cab-d2e11ba03753
        Total devices 1 FS bytes used 17.18GB
        devid    2 size 1.62TB used 101.12GB path /dev/sdc4


$ uname -r
3.3.2-1.fc16.x86_64

btrfs-progs version is current git master ( commit 1957076 )

After writing this email, and searching around the wiki some, I
discovered the command to resize specific devids,

[antrat@tbox ~]$ sudo btrfs fi resize 2:max /
Resize '/' of '2:max'

and in dmesg:
[ 1661.933884] btrfs: resizing devid 2
[ 1661.933895] btrfs: new size for /dev/sdc4 is 1995564908544
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html