Continuing: gdb bt now gives:
#0 0x000000000042075a in btrfs_search_slot () #1 0x0000000000427bb4 in btrfs_read_block_groups () #2 0x0000000000423e40 in btrfs_setup_all_roots () #3 0x000000000042406d in __open_ctree_fd () #4 0x0000000000424126 in open_ctree_fs_info () #5 0x000000000041812e in cmd_check () #6 0x0000000000404904 in main () #0 0x00000000004208bc in btrfs_search_slot () #1 0x0000000000427bb4 in btrfs_read_block_groups () #2 0x0000000000423e40 in btrfs_setup_all_roots () #3 0x000000000042406d in __open_ctree_fd () #4 0x0000000000424126 in open_ctree_fs_info () #5 0x000000000041812e in cmd_check () #6 0x0000000000404904 in main () #0 0x00000000004208d0 in btrfs_search_slot () #1 0x0000000000427bb4 in btrfs_read_block_groups () #2 0x0000000000423e40 in btrfs_setup_all_roots () #3 0x000000000042406d in __open_ctree_fd () #4 0x0000000000424126 in open_ctree_fs_info () #5 0x000000000041812e in cmd_check () #6 0x0000000000404904 in main () Still no further output. btrfsck running at 100% on a single core and with no apparent disk activity. All for a 2TB hdd. Should it take this long?... Regards, Martin On 15/11/13 17:18, Martin wrote: > Another two days and a backtrace shows the hope of progress: > > #0 0x000000000041de2f in btrfs_node_key () > #1 0x000000000041ee79 in btrfs_check_node () > #2 0x0000000000420211 in check_block () > #3 0x0000000000420813 in btrfs_search_slot () > #4 0x0000000000427bb4 in btrfs_read_block_groups () > #5 0x0000000000423e40 in btrfs_setup_all_roots () > #6 0x000000000042406d in __open_ctree_fd () > #7 0x0000000000424126 in open_ctree_fs_info () > #8 0x000000000041812e in cmd_check () > #9 0x0000000000404904 in main () > > No other output, 100% CPU, using only a single core, and no apparent > disk activity. > > There looks to be a repeating pattern of calls. Is this working though > the same test repeated per btrfs block? Are there any variables that can > be checked with gdb to see how far it has gone so as to guess how long > it might need to run? > > > Phew? > > Hope of interest, > > Regards, > Martin > > > > > On 13/11/13 12:08, Martin wrote: >> On 11/11/13 22:52, Martin wrote: >>> On 07/11/13 01:25, Martin wrote: >> >>> OK so Chris Mason and the Gentoo sys-fs/btrfs-progs-9999 came to the >>> rescue to give: >>> >>> >>> # btrfs version >>> Btrfs v0.20-rc1-591-gc652e4e >> >>> From that, I've tried running again: >>> >>> # btrfsck --repair /dev/sdc >>> >>> giving thus far: >>> >>> parent transid verify failed on 911904604160 wanted 17448 found 17450 >>> parent transid verify failed on 911904604160 wanted 17448 found 17450 >>> parent transid verify failed on 911904604160 wanted 17448 found 17450 >>> parent transid verify failed on 911904604160 wanted 17448 found 17450 >>> Ignoring transid failure >>> >>> >>> ... And it is still running a couple of days later. >>> >>> GDB shows: >>> >>> (gdb) bt >>> #0 0x000000000042d576 in read_extent_buffer () >>> #1 0x000000000041ee79 in btrfs_check_node () >>> #2 0x0000000000420211 in check_block () >>> #3 0x0000000000420813 in btrfs_search_slot () >>> #4 0x0000000000427bb4 in btrfs_read_block_groups () >>> #5 0x0000000000423e40 in btrfs_setup_all_roots () >>> #6 0x000000000042406d in __open_ctree_fd () >>> #7 0x0000000000424126 in open_ctree_fs_info () >>> #8 0x000000000041812e in cmd_check () >>> #9 0x0000000000404904 in main () >> >> >> Another two days and: >> >> (gdb) bt >> #0 0x000000000042373a in read_tree_block () >> #1 0x0000000000421538 in btrfs_search_slot () >> #2 0x0000000000427bb4 in btrfs_read_block_groups () >> #3 0x0000000000423e40 in btrfs_setup_all_roots () >> #4 0x000000000042406d in __open_ctree_fd () >> #5 0x0000000000424126 in open_ctree_fs_info () >> #6 0x000000000041812e in cmd_check () >> #7 0x0000000000404904 in main () >> >> >>> So... Has it looped or is it busy? There is no activity on /dev/sdc. >> >> Same "btrfs_read_block_groups" but different stack above that: So >> perhaps something useful is being done?... >> >> No disk activity noticed. >> >> >>> Which comes to a request: >>> >>> Can the options "-v" (for verbose) and "-s" (to continuously show >>> status) be added to btrfsck to give some indication of progress and what >>> is happening? The "-s" should report progress by whatever appropriate >>> real-time counts as done by such as "badblocks -s". -- 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
