Description of problem: System hung during btrfs device add or delete (I forget which as I was updating several different file systems) and now complains about the chunk tree when you attempt to mount. btrfs rescue chunk asserts when recovery attempted. Chunk tree error upon mount attempt: [31444.032878] btrfs: disk space caching is enabled [31444.046704] parent transid verify failed on 1030855073792 wanted 160415 found 159405 [31444.149448] parent transid verify failed on 1030855073792 wanted 160415 found 159405 [31444.149454] btrfs: failed to read chunk root on dm-11 [31444.160498] btrfs: open_ctree failed Error when attempting recovery. Note that the 4 devices reporting errors are not part of this btrfs pool: # btrfs rescue chunk -v -y /dev/mapper/luks-283a637d-3382-47a3-bd70-4956060c9a19 /dev/mapper/luks-51102b55-d0d2-474e-a2d1-d6efa557a20f /dev/mapper/luks-ee66a1db-ed20-48e1-809b-1e0ade2dfec0 /dev/mapper/luks-d0568fb6-1e41-404e-a4a2-a8cfd9ba7e8f ERROR: device scan failed '/dev/sdf1' - Invalid argument ERROR: device scan failed '/dev/sdm1' - Device or resource busy ERROR: device scan failed '/dev/sdi1' - Device or resource busy ERROR: device scan failed '/dev/md126' - Invalid argument All Devices: Device: id = 1, name = /dev/dm-13 Device: id = 2, name = /dev/dm-12 Device: id = 3, name = /dev/dm-11 Device: id = 4, name = /dev/dm-10 btrfs: chunk-recover.c:124: process_extent_buffer: Assertion `!(exist->nmirrors >= 2)' failed. Aborted (core dumped) Version-Release number of selected component: btrfs-progs-0.20.rc1.20131114git9f0c53f-1.fc20 Additional info: reporter: libreport-2.1.9 backtrace_rating: 4 cmdline: btrfs rescue chunk -v -y /dev/mapper/luks-283a637d-3382-47a3-bd70-4956060c9a19 /dev/mapper/luks-51102b55-d0d2-474e-a2d1-d6efa557a20f /dev/mapper/luks-ee66a1db-ed20-48e1-809b-1e0ade2dfec0 /dev/mapper/luks-d0568fb6-1e41-404e-a4a2-a8cfd9ba7e8f crash_function: process_extent_buffer executable: /usr/sbin/btrfs kernel: 3.11.10-301.fc20.x86_64 runlevel: N 5 type: CCpp uid: 0 Truncated backtrace: Thread no. 1 (5 frames) #4 process_extent_buffer at chunk-recover.c:124 #5 scan_one_device at chunk-recover.c:757 #6 scan_devices at chunk-recover.c:804 #7 btrfs_recover_chunk_tree at chunk-recover.c:1655 #8 cmd_chunk_recover at cmds-rescue.c:88
Created attachment 896820 [details] File: backtrace
Created attachment 896821 [details] File: cgroup
Created attachment 896822 [details] File: core_backtrace
Created attachment 896823 [details] File: dso_list
Created attachment 896824 [details] File: environ
Created attachment 896825 [details] File: limits
Created attachment 896826 [details] File: maps
Created attachment 896827 [details] File: open_fds
Created attachment 896828 [details] File: proc_pid_status
Created attachment 896829 [details] File: var_log_messages
btrfs-progs 3.14.1 is now available for Fedora 20, can you give that a shot and see if you have any more luck on the userspace side of things? Thanks, -Eric
(Currently in the testing repo, sorry, should have mentioned that)
Thanks for the prompt response. I've updated to btrfs-progs-3.14.1-1.fc20.x86_64 and kicked off another rescue operation. One difference I notice is that it seems to be multi-threaded now and hammering multiple disks at once whereas before I only noticed activity on one disk at a time - coincidence or related to changes in the new version?
Re-adding info request flag as I haven't got the results yet.
(In reply to Matt Hooper from comment #13) > Thanks for the prompt response. I've updated to > btrfs-progs-3.14.1-1.fc20.x86_64 and kicked off another rescue operation. > > One difference I notice is that it seems to be multi-threaded now and > hammering multiple disks at once whereas before I only noticed activity on > one disk at a time - coincidence or related to changes in the new version? No clue, I'm afraid. That old 0.20-git version was ancient, lots of changes in between: $ git log --oneline 9f0c53f..v3.14.1 | wc -l 137 but nothing in the logs specifically about rescue: $ git log --oneline 9f0c53f..v3.14.1 | grep -i rescue $ and the rescue file itself has barely changed: $ git log --oneline 9f0c53f..v3.14.1 cmds-rescue.c 51a40f6 btrfs-progs: judge the return value of check_mounted more accurately $ -Eric
Sadly it crashed again. Abrt created bug #1099224 for the new crash
Ok, thanks for trying. I'll dup this one to that one, they are apparently the same problem. *** This bug has been marked as a duplicate of bug 1099224 ***