From: james harvey <jamespharvey20@gmail.com>
To: Qu Wenruo <wqu@suse.com>
Cc: Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH] btrfs-progs: check: Also compare data between mirrors to detect corruption for NODATASUM extents
Date: Tue, 29 May 2018 15:26:13 -0400 [thread overview]
Message-ID: <CA+X5Wn6Ltx02naOh2BjZwzu2A2c74G47QAceMipt-XsoCS2k+A@mail.gmail.com> (raw)
In-Reply-To: <20180529074527.7333-1-wqu@suse.com>
On Tue, May 29, 2018 at 3:45 AM, Qu Wenruo <wqu@suse.com> wrote:
> As the lzo corruption reported by James Harvey, for data extents without
> checksum, neither btrfs check nor kernel scrub could detect anything
> wrong.
>
> However if our profile supports duplication, we still have a chance to
> detect such corruption, as in that case the mirrors will mismatch with
> each other.
>
> So enhance --check-data-csum option to do such check, and this could
> help us to detect such corruption in an autonomous test case.
>
> Signed-off-by: Qu Wenruo <wqu@suse.com>
I think it's good to have check --check-data-csum do such check.
I also think there should be a check option that only checks the
mirrored copies, so it could be ran without taking the time to check
everything that scrub looks at. (If the feature isn't also added to
scrub as I argue for below, one could run this option every time they
scrub.)
IMO, it is important to also add this to scrub. First reason is to
allow online scanning, since check is recommended not to run with
--force on a quiescent/read-only fs. Second, I think users expect
scrub to ensure mirrored data integrity, and this goes along with
that, of course without automatic correction. I think without doing
so, users who periodically run scrub would be surprised if they had
data corruption, that it hadn't been being checked all along.
It's recommended many places that users setup scrub to run
automatically on a periodic basis, but I'm not sure if I've seen
anywhere recommend setting up check to do so as well, especially as
doing so on a mounted filesystem is discouraged and potentially will
crash.
I haven't looked at this specifically, but I'm thinking this would be
better in the btrfs-progs side of scrub after it runs the kernel side
real scrub.
I have to head out for a while. I haven't looked over or tried the
code yet, but will later.
prev parent reply other threads:[~2018-05-29 19:26 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-29 7:45 [PATCH] btrfs-progs: check: Also compare data between mirrors to detect corruption for NODATASUM extents Qu Wenruo
2018-05-29 8:59 ` Su Yue
2018-05-29 9:28 ` Lu Fengqi
2018-05-29 19:26 ` james harvey [this message]
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=CA+X5Wn6Ltx02naOh2BjZwzu2A2c74G47QAceMipt-XsoCS2k+A@mail.gmail.com \
--to=jamespharvey20@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=wqu@suse.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).