linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marc MERLIN <marc@merlins.org>
To: Qu Wenruo <quwenruo@cn.fujitsu.com>
Cc: David Sterba <dsterba@suse.com>, Hugo Mills <hugo@carfax.org.uk>,
	linux-btrfs@vger.kernel.org
Subject: Re: btrfs support for filesystems >8TB on 32bit architectures
Date: Tue, 8 Nov 2016 18:05:19 -0800	[thread overview]
Message-ID: <20161109020519.GN13371@merlins.org> (raw)
In-Reply-To: <f17792e9-498a-4ff0-2cc5-674ae10a01ad@cn.fujitsu.com>

On Wed, Nov 09, 2016 at 09:50:08AM +0800, Qu Wenruo wrote:
> Yeah, quite possible!
> 
> The truth is, current btrfs check only checks:
> 1) Metadata
>    while --check-data-csum option will check data, but still
>    follow the restriction 3).
> 2) Crossing reference of metadata (contents of metadata)
> 3) The first good mirror/backup
> 
> So quite a lot of problems can't be detected by btrfs check:
> 1) Data corruption (csum mismatch)
> 2) 2nd mirror corruption(DUP/RAID0/10) or parity error(RAID5/6)
> 
> For btrfsck to check all mirror and data, you could try out-of-tree 
> offline scrub patchset:
> https://github.com/adam900710/btrfs-progs/tree/fsck_scrub
> 
> Which implements the kernel scrub equivalent in btrfs-progs.

I see, thanks for the answer.
Note that this is very confusing to the end user.
If check --repair returns success, the filesystem should be clean.
Hopefully that patchset can be included in btrfs-progs

But sure enough, I'm seeing a lot of these:
BTRFS warning (device dm-6): checksum error at logical 269783986176 on dev /dev/mapper/crypt_bcache2, sector 529035384, root 16755, inode 1225897, offset 77824, length 4096, links 5 (path: magic/20150624/home/merlin/public_html/rig3/img/thumb800_302_1-Wire.jpg)

This is bad because I would expect check --repair to find them all and offer
to remove all the corrupted files after giving me a list of what I've lost,
or just recompute the checksum to be correct, know the file is now corrupted
but "clean" and I have the option of keeping them as is (ok-ish for a video
file) or restore them from backup.

The worst part with scrub is that I have to find all these files, and then
find all the snapshots they're in (maybe 10 or 20) and delete them all, and
then some of those snapshots are read only because they are btrfs send
source, so I need to destroy those snapshots and lose my btrfs send
relationship and am forced to recreate it (maybe 2 to 6 days of syncing over
a slow-ish link)

When data is corrupted, no solution is perfect, but hopefully check --repair
will indeed be able to restore the entire filesystem to a clean state, even
if some data must be lost in the process.

Thanks for considering.

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/  

  reply	other threads:[~2016-11-09  2:06 UTC|newest]

Thread overview: 40+ 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
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 [this message]
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

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=20161109020519.GN13371@merlins.org \
    --to=marc@merlins.org \
    --cc=dsterba@suse.com \
    --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).