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

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

Reply via email to