It's now gone back to a pattern from a full week ago: (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 ()
I don't know if that has gone through that pattern during the week but at a-week-a-time, this is not going to finish in reasonable time. How come so very slow? Any hints/tips/fixes or abandon the test? Regards, Martin On 19/11/13 06:34, Martin wrote: > 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 > -- 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
