From: Marc MERLIN <marc@merlins.org>
To: Hugo Mills <hugo@carfax.org.uk>,
Qu Wenruo <quwenruo@cn.fujitsu.com>,
linux-btrfs@vger.kernel.org
Subject: Re: btrfs check --repair: ERROR: cannot read chunk root
Date: Mon, 31 Oct 2016 20:48:11 -0700 [thread overview]
Message-ID: <20161101034811.gugus2a5rsqnixuo@merlins.org> (raw)
In-Reply-To: <20161031150422.GQ28648@merlins.org>
So, I'm willing to wait 2 more days before I wipe this filesystem and
start over if I can't get check --repair to work on it.
If you need longer, please let me konw you have an upcoming patch for me
to try and I'll wait.
Thanks,
Marc
On Mon, Oct 31, 2016 at 08:04:22AM -0700, Marc MERLIN wrote:
> On Mon, Oct 31, 2016 at 08:44:12AM +0000, Hugo Mills wrote:
> > > Any idea on special dm setup which can make us fail to read out some
> > > data range?
> >
> > I've seen both btrfs check and btrfs dump-super give wrong answers
> > (particularly, some addresses end up larger than the device, for some
> > reason) when run on a mounted filesystem. Worth ruling that one out.
>
> I just finished running my scrub overnight, and it failed around 10%:
> [115500.316921] BTRFS error (device dm-0): bad tree block start 8461247125784585065 17619396231168
> [115500.332354] BTRFS error (device dm-0): bad tree block start 8461247125784585065 17619396231168
> [115500.332626] BTRFS: error (device dm-0) in __btrfs_free_extent:6954: errno=-5 IO failure
> [115500.332629] BTRFS info (device dm-0): forced readonly
> [115500.332632] BTRFS: error (device dm-0) in btrfs_run_delayed_refs:2960: errno=-5 IO failure
> [115500.436002] btrfs_printk: 550 callbacks suppressed
> [115500.436024] BTRFS warning (device dm-0): Skipping commit of aborted transaction.
> [115500.436029] BTRFS: error (device dm-0) in cleanup_transaction:1854: errno=-5 IO failure
>
>
> myth:~# ionice -c 3 nice -10 btrfs scrub start -Bd /mnt/mnt
> (...)
> scrub device /dev/mapper/crypt_bcache0 (id 1) canceled
> scrub started at Sun Oct 30 22:52:59 2016 and was aborted after 09:03:11
> total bytes scrubbed: 1.15TiB with 512 errors
> error details: csum=512
> corrected errors: 0, uncorrectable errors: 512, unverified errors: 0
>
> Am I correct that if I see "__btrfs_free_extent:6954: errno=-5 IO failure" it means
> that btrfs had physical read errors from the underlying block layer?
>
> Do I have some weird mismatch between the size of my md array and the size of my filesystem
> (as per dd apparently thinking parts of it are out of bounds?)
> Yet, the sizes seem to match:
>
>
> myth:~# mdadm --query --detail /dev/md5
> /dev/md5:
> Version : 1.2
> Creation Time : Tue Jan 21 10:35:52 2014
> Raid Level : raid5
> Array Size : 15627542528 (14903.59 GiB 16002.60 GB)
> Used Dev Size : 3906885632 (3725.90 GiB 4000.65 GB)
> Raid Devices : 5
> Total Devices : 5
> Persistence : Superblock is persistent
>
> Intent Bitmap : Internal
>
> Update Time : Mon Oct 31 07:56:07 2016
> State : clean
> Active Devices : 5
> Working Devices : 5
> Failed Devices : 0
> Spare Devices : 0
>
> Layout : left-symmetric
> Chunk Size : 512K
>
> Name : gargamel.svh.merlins.org:5
> UUID : ec672af7:a66d9557:2f00d76c:38c9f705
> Events : 147992
>
> Number Major Minor RaidDevice State
> 0 8 97 0 active sync /dev/sdg1
> 6 8 113 1 active sync /dev/sdh1
> 2 8 81 2 active sync /dev/sdf1
> 3 8 65 3 active sync /dev/sde1
> 5 8 49 4 active sync /dev/sdd1
>
> myth:~# btrfs fi df /mnt/mnt
> Data, single: total=13.22TiB, used=13.19TiB
> System, DUP: total=32.00MiB, used=1.42MiB
> Metadata, DUP: total=75.00GiB, used=72.82GiB
> GlobalReserve, single: total=512.00MiB, used=6.73MiB
>
> Thanks,
> Marc
> --
> "A mouse is a device used to point at the xterm you want to type in" - A.S.R.
> Microsoft is to operating systems ....
> .... what McDonalds is to gourmet cooking
> Home page: http://marc.merlins.org/
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ | PGP 1024R/763BE901
next prev parent reply other threads:[~2016-11-01 3:48 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-30 18:34 btrfs check --repair: ERROR: cannot read chunk root Marc MERLIN
2016-10-31 1:02 ` Qu Wenruo
2016-10-31 2:06 ` Marc MERLIN
2016-10-31 4:21 ` Marc MERLIN
2016-10-31 5:27 ` Qu Wenruo
2016-10-31 5:47 ` Marc MERLIN
2016-10-31 6:04 ` Qu Wenruo
2016-10-31 6:25 ` Marc MERLIN
2016-10-31 6:32 ` Qu Wenruo
2016-10-31 6:37 ` Marc MERLIN
2016-10-31 7:04 ` Qu Wenruo
2016-10-31 8:44 ` Hugo Mills
2016-10-31 15:04 ` Marc MERLIN
2016-11-01 3:48 ` Marc MERLIN [this message]
2016-11-01 4:13 ` Qu Wenruo
2016-11-01 4:21 ` Marc MERLIN
2016-11-04 8:01 ` Marc MERLIN
2016-11-04 9:00 ` Roman Mamedov
2016-11-04 17:59 ` Marc MERLIN
2016-11-07 1:11 ` Qu Wenruo
[not found] ` <87lgwwnnyf.fsf@notabene.neil.brown.name>
2016-11-07 1:20 ` clearing blocks wrongfully marked as bad if --update=no-bbl can't be used? Marc MERLIN
2016-11-07 1:39 ` Qu Wenruo
2016-11-07 4:18 ` Qu Wenruo
2016-11-07 5:36 ` btrfs support for filesystems >8TB on 32bit architectures Marc MERLIN
2016-11-07 6:16 ` Qu Wenruo
2016-11-07 14:55 ` Marc MERLIN
2016-11-08 0:35 ` Qu Wenruo
2016-11-08 0:39 ` Marc MERLIN
2016-11-08 0:43 ` Qu Wenruo
2016-11-08 1:06 ` Marc MERLIN
2016-11-08 1:17 ` Qu Wenruo
2016-11-08 15:24 ` Marc MERLIN
2016-11-09 1:50 ` Qu Wenruo
2016-11-09 2:05 ` Marc MERLIN
2016-11-11 3:48 ` Marc MERLIN
2016-11-11 3:55 ` Qu Wenruo
2016-11-12 3:17 ` when btrfs scrub reports errors and btrfs check --repair does not Marc MERLIN
2016-11-13 15:06 ` Marc MERLIN
2016-11-13 15:13 ` Roman Mamedov
2016-11-13 15:52 ` Marc MERLIN
-- strict thread matches above, loose matches on Subject: below --
2016-10-31 1:29 btrfs check --repair: ERROR: cannot read chunk root Janos Toth F.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161101034811.gugus2a5rsqnixuo@merlins.org \
--to=marc@merlins.org \
--cc=hugo@carfax.org.uk \
--cc=linux-btrfs@vger.kernel.org \
--cc=quwenruo@cn.fujitsu.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).