Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org, stable@vger.kernel.org
Cc: David Sterba <dsterba@suse.com>
Subject: [PATCH STABLE 5.19 0/2] btrfs: raid56: backports to reduce corruption
Date: Fri, 19 Aug 2022 15:01:37 +0800	[thread overview]
Message-ID: <cover.1660891713.git.wqu@suse.com> (raw)

This backport is going to address the following possible corruption for
btrfs RAID56:

- RMW always writes the full P/Q stripe
  This happens even only some vertical stripes are dirty.

  If some data sectors are corrupted in the clean vertical stripes,
  then such unnecessary P/Q updates will wipe the chance or recovery,
  as the P/Q will be calculated using corrupted data.

  This will be addressed by the first backport patch.

- Don't trust any cached sector when doing recovery
  Although above patch will avoid unnecessary P/Q writes, the full P/Q
  stripe will still be updated in the in-memory only RAID56 cache.

  To properly recovery data stripes, we should not trust any cached
  sector, and always read data from disk, which will avoid corrupted
  P/Q sectors.

  This will be addressed by the second backport patch.

This would make some previously always-fail test cases, like btrfs/125,
to pass, and end users have a lower chance to corrupt their RAID56 data.

Since this is a data corruption related fix, these backport patches are
needed for all stable branches.

Unfortunately due to the new cleanups in v6.0-rc, these backport patches
have quite some conflicts (even for 5.19), and have to be manually resolved.
Almost every stable branch will need their own backports.

Acked-by: David Sterba <dsterba@suse.com>

Qu Wenruo (2):
  btrfs: only write the sectors in the vertical stripe which has data
    stripes
  btrfs: raid56: don't trust any cached sector in
    __raid56_parity_recover()

 fs/btrfs/raid56.c | 68 ++++++++++++++++++++++++++++++++++++++---------
 1 file changed, 55 insertions(+), 13 deletions(-)

-- 
2.37.1


             reply	other threads:[~2022-08-19  7:02 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-19  7:01 Qu Wenruo [this message]
2022-08-19  7:01 ` [PATCH STABLE 5.19 1/2] btrfs: only write the sectors in the vertical stripe which has data stripes Qu Wenruo
2022-08-19  7:01 ` [PATCH STABLE 5.19 2/2] btrfs: raid56: don't trust any cached sector in __raid56_parity_recover() Qu Wenruo
2022-08-19  7:08 ` [PATCH STABLE 5.19 0/2] btrfs: raid56: backports to reduce corruption Qu Wenruo
2022-08-19  7:18   ` Greg KH

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=cover.1660891713.git.wqu@suse.com \
    --to=wqu@suse.com \
    --cc=dsterba@suse.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    /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