3.6.3-3.fc18.x86_64.debug
btrfs-progs-0.20.rc1.20121017git91d9eec-1.fc18.x86_64

I'm getting a very different result with this kernel compared to 3.6.2, when I do the same thing. I fill the btrfs volume to 97% full again, no errors. Add a device of the *same* size, and then device delete.

In this case, the 'device delete' command hangs, no recovery, and dmesg from another shell reports the file system is forced read only. The debug kernel produces quite a bit more information so I'll post that here:

http://pastebin.com/8d1b6eCn


Label: 'filltest'  uuid: c0a4c7d7-7a23-4ce3-bafe-20cb92156562
	Total devices 3 FS bytes used 13.84GB
	devid    3 size 8.00GB used 19.00MB path /dev/sdd
	devid    2 size 8.00GB used 8.00GB path /dev/sdc
	devid    1 size 8.00GB used 8.00GB path /dev/sdb


[root@f18v ~]# btrfs fi df /mnt
Data, RAID0: total=13.95GB, used=13.82GB
Data: total=8.00MB, used=0.00
System, RAID1: total=8.00MB, used=4.00KB
System: total=4.00MB, used=0.00
Metadata, RAID1: total=1.02GB, used=19.09MB
Metadata: total=8.00MB, used=0.00

Two minutes later I get more from dmesg since btrfs is blocked:

http://pastebin.com/BznS3dF0

The volume can't be unmounted and the stuck process can't be killed. So I reboot. Mounting it produces:

[   45.540143] device label filltest devid 1 transid 17 /dev/sdb
[   45.545417] btrfs: disk space caching is enabled
[   45.566326] btrfs: free space inode generation (0) did not match free space cache generation (1858)
[   45.598677] btrfs: free space inode generation (0) did not match free space cache generation (1832)
[   45.794886] btrfs: unlinked 1 orphans

Otherwise the file system seems fine. And

btrfs balance start -dconvert=single /mnt

Does eventually unwind the problem.

If the scenario allows adding a 4th device to this situation, it's faster because the balance isn't required. Thus deleting the (hypothetically troublesome) device occurs more quickly while also not requiring significant write capability to it.


Chris Murphy