From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH v2 0/5] btrfs-progs: check: properly generate csum for various complex combinations
Date: Fri, 14 Jan 2022 08:51:18 +0800 [thread overview]
Message-ID: <20220114005123.19426-1-wqu@suse.com> (raw)
[BUG]
Issue #420 mentions that --init-csum-tree creates extra csum for
preallocated extents.
Causing extra errors after --init-csum-tree.
[CAUSE]
Csum re-calculation code doesn't take the following factors into
consideration:
- NODATASUM inodes
- Preallocated extents
No csum should be calculated for those data extents
- Partically written preallocated csum
Csum should only be created for the referred part
So currently csum recalculation will just create csum for any data
extents it found, causing the mentioned errors.
[FIX]
- Bug fix for backref iteration
Firstly fix a bug in backref code where indirect ref is not properly
resolved.
This allows us to use iterate_extent_inodes() to make our lives much
easier checking the file extents.
- Code move for --init-csum-tree
Move it to mode independent mode-common.[ch]
- Fix for --init-csum-tree
There are some extreme corner cases to consider, in fact we can not
really determine a range should have csum or not:
* Preallocated, written, then hole punched range
Should still have csum for the written (now hole) part.
* Preallocated, then hole punched range.
Should not have csum for the now hole part.
* Regular written extent, then hole punched range
Should have csum for the now hole part.
But there is still one thing to follow, if a range is preallocated,
it should not have csum.
So here we go a different route, by always generate csum for the whole
extent (as long as it's not belonging to NODATASUM inode), then remove
csums for preallocated range.
- Fix for --init-csum-tree --init-extent-tree
The same fix, just into a different context
- New test case
[CHANGELOG]
v2:
- Handle written extents then hole punched cases
Now we always generate csum for a data extent as long as it doesn't
belong to a NODATASUM inode, then remove the csum for preallocated
range.
- Enhance test case to include hole punching and compressed extents
Qu Wenruo (5):
btrfs-progs: backref: properly queue indirect refs
btrfs-progs: check: move csum tree population into mode-common.[ch]
btrfs-progs: check: don't calculate csum for preallocated file extents
btrfs-progs: check: handle csum generation properly for
`--init-csum-tree --init-extent-tree`
btrfs-progs: fsck-tests: add test case for init-csum-tree
check/main.c | 244 ------------
check/mode-common.c | 393 ++++++++++++++++++++
check/mode-common.h | 1 +
kernel-shared/backref.c | 10 +-
tests/fsck-tests/052-init-csum-tree/test.sh | 72 ++++
5 files changed, 474 insertions(+), 246 deletions(-)
create mode 100755 tests/fsck-tests/052-init-csum-tree/test.sh
--
2.34.1
next reply other threads:[~2022-01-14 0:51 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-14 0:51 Qu Wenruo [this message]
2022-01-14 0:51 ` [PATCH v2 1/5] btrfs-progs: backref: properly queue indirect refs Qu Wenruo
2022-01-14 0:51 ` [PATCH v2 2/5] btrfs-progs: check: move csum tree population into mode-common.[ch] Qu Wenruo
2022-01-14 0:51 ` [PATCH v2 3/5] btrfs-progs: check: don't calculate csum for preallocated file extents Qu Wenruo
2022-01-14 0:51 ` [PATCH v2 4/5] btrfs-progs: check: handle csum generation properly for `--init-csum-tree --init-extent-tree` Qu Wenruo
2022-01-14 0:51 ` [PATCH v2 5/5] btrfs-progs: fsck-tests: add test case for init-csum-tree Qu Wenruo
2022-01-14 16:40 ` David Sterba
2022-01-14 23:40 ` Qu Wenruo
2022-01-17 13:50 ` David Sterba
2022-01-14 16:50 ` [PATCH v2 0/5] btrfs-progs: check: properly generate csum for various complex combinations David Sterba
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=20220114005123.19426-1-wqu@suse.com \
--to=wqu@suse.com \
--cc=linux-btrfs@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;
as well as URLs for NNTP newsgroup(s).