From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from plane.gmane.org ([80.91.229.3]:33429 "EHLO plane.gmane.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750980Ab3KSGem (ORCPT ); Tue, 19 Nov 2013 01:34:42 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VietV-0001Fb-Ba for linux-btrfs@vger.kernel.org; Tue, 19 Nov 2013 07:34:41 +0100 Received: from cpc21-stap10-2-0-cust974.12-2.cable.virginm.net ([86.0.163.207]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 19 Nov 2013 07:34:41 +0100 Received: from m_btrfs by cpc21-stap10-2-0-cust974.12-2.cable.virginm.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 19 Nov 2013 07:34:41 +0100 To: linux-btrfs@vger.kernel.org From: Martin Subject: Re: [PATCH] Btrfs-progs: allow --init-extent-tree to work when extent tree is borked Date: Tue, 19 Nov 2013 06:34:30 +0000 Message-ID: References: <1382724100-5276-1-git-send-email-jbacik@fusionio.com> <20131025183134.GA4543@localhost.localdomain> <20131028151148.GB4543@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 In-Reply-To: Sender: linux-btrfs-owner@vger.kernel.org List-ID: 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".