All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roman Mamedov <rm@romanrm.net>
To: Marc MERLIN <marc@merlins.org>
Cc: Qu Wenruo <quwenruo@cn.fujitsu.com>,
	Hugo Mills <hugo@carfax.org.uk>,
	linux-btrfs@vger.kernel.org
Subject: Re: btrfs check --repair: ERROR: cannot read chunk root
Date: Fri, 4 Nov 2016 14:00:43 +0500	[thread overview]
Message-ID: <20161104140043.5d739dc9@natsu> (raw)
In-Reply-To: <20161104080113.GG3529@merlins.org>

On Fri, 4 Nov 2016 01:01:13 -0700
Marc MERLIN <marc@merlins.org> wrote:

> Basically I have this:
> sde                            8:64   0   3.7T  0 
> └─sde1                         8:65   0   3.7T  0 
>   └─md5                        9:5    0  14.6T  0 
>     └─bcache0                252:0    0  14.6T  0 
>       └─crypt_bcache0 (dm-0) 253:0    0  14.6T  0 
> 
> I'll try dd'ing the md5 directly now, but that's going to take another 2 days :(
> 
> That said, given that almost half the device is not readable from user space
> for some reason, that would explain why btrfs check is failing. Obviously it
> can't do its job if it can't read blocks.

I don't see anything to support the notion that "half is unreadable", maybe
just a 512-byte sector is unreadable -- but that would be enough to make
regular dd bail out -- which is why you should be using dd_rescue for this,
not regular dd. Assuming you just want to copy over as much data as possible,
and not simply test if dd fails or not (but in any case dd_rescue at least
would not fail instantly and would tell you precise count of how much is
unreadable).

There is "GNU ddrescue" and "dd_rescue", I liked the first one better, but
they both work on a similar principle.

Also didn't you recently have issues with bad block lists on mdadm. This
mysterious "unreadable and nothing in dmesg" does appear to be a continuation
of that.

-- 
With respect,
Roman

  reply	other threads:[~2016-11-04  9:00 UTC|newest]

Thread overview: 67+ 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
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 [this message]
2016-11-04 17:59                               ` Marc MERLIN
2016-11-07  1:11                             ` Qu Wenruo
  -- strict thread matches above, loose matches on Subject: below --
2016-10-31  1:29 Janos Toth F.
2016-10-30  2:16 Buffer I/O error on dev md5, logical block 7073536, async page read Marc MERLIN
2016-10-30  9:33 ` Andreas Klauer
2016-10-30 15:38   ` Marc MERLIN
2016-10-30 16:19     ` Andreas Klauer
2016-10-30 16:34       ` Phil Turmel
2016-10-30 17:12         ` clearing blocks wrongfully marked as bad if --update=no-bbl can't be used? Marc MERLIN
2016-10-30 17:16           ` Marc MERLIN
2016-11-04 18:18             ` Marc MERLIN
2016-11-04 18:22               ` Phil Turmel
2016-11-04 18:50                 ` Marc MERLIN
2016-11-04 18:59                   ` Roman Mamedov
2016-11-04 19:31                     ` Roman Mamedov
2016-11-04 20:02                       ` Marc MERLIN
2016-11-04 19:51                     ` Marc MERLIN
2016-11-07  0:16                       ` NeilBrown
2016-11-07  1:13                         ` Marc MERLIN
2016-11-07  3:36                           ` Phil Turmel
2016-11-07  1:20                         ` 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
2016-10-30 18:56         ` [ LR] Kernel 4.8.4: INFO: task kworker/u16:8:289 blocked for more than 120 seconds TomK
2016-10-30 19:16           ` TomK
2016-10-30 20:13           ` Andreas Klauer
2016-10-30 21:08             ` TomK
2016-10-31 19:29           ` Wols Lists
2016-11-01  2:40             ` TomK
2016-10-30 16:43       ` Buffer I/O error on dev md5, logical block 7073536, async page read Marc MERLIN
2016-10-30 17:02         ` Andreas Klauer
2016-10-31 19:24         ` Wols Lists

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=20161104140043.5d739dc9@natsu \
    --to=rm@romanrm.net \
    --cc=hugo@carfax.org.uk \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=marc@merlins.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.