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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
