From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH v2 0/5] btrfs: detect and fix the ram_bytes mismatch
Date: Wed, 26 Jun 2024 11:17:28 +0930 [thread overview]
Message-ID: <cover.1719366258.git.wqu@suse.com> (raw)
[CHANGELOG]
v2:
- Add the missing patch fixing ram_bytes
Now the 2nd patch would ignore the incorrect value and use a correct
one from btrfs_file_extent_item::disk_num_bytes.
- Update the commit messages to fix my usual "would" and other grammar
errors
There is a long existing mismatch between ram_bytes and disk_num_bytes
for regular non-compressed data extents.
It turns out to be caused by truncated ordered extents, which modified
ram_bytes unnecessarily.
Thankfully this is not going to cause any data corruption or whatever,
kernel can handle it correctly without any extra problem.
It's only a small violation on the on-disk format.
This series would fix by:
- Cleanup the @bytenr usage inside btrfs_extent_item_to_extent_map()
- Override the ram_bytes when reading file extent items from disk
So that we always get correct extent maps even if the on-disk one is
incorrect.
- Add an extra check on extent_map members
- Add the proper fix for the ram_bytes mismatch
- Add a tree-checker for the ram_bytes mismatch
Since we can have on-disk ram_bytes incorrect already, this check is
only for DEBUG and ASSERT builds, and it won't report error but only
does a kernel warning for us to catch.
Qu Wenruo (5):
btrfs: cleanup the bytenr usage inside
btrfs_extent_item_to_extent_map()
btrfs: ignore incorrect btrfs_file_extent_item::ram_bytes
btrfs: make validate_extent_map() to catch ram_bytes mismatch
btrfs: fix the ram_bytes assignment for truncated ordered extents
btrfs: tree-checker: add extra ram_bytes and disk_num_bytes check
fs/btrfs/extent_map.c | 5 +++++
fs/btrfs/file-item.c | 16 +++++++++++-----
fs/btrfs/inode.c | 4 +---
fs/btrfs/tree-checker.c | 18 ++++++++++++++++++
4 files changed, 35 insertions(+), 8 deletions(-)
--
2.45.2
next reply other threads:[~2024-06-26 1:47 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-26 1:47 Qu Wenruo [this message]
2024-06-26 1:47 ` [PATCH v2 1/5] btrfs: cleanup the bytenr usage inside btrfs_extent_item_to_extent_map() Qu Wenruo
2024-06-26 1:47 ` [PATCH v2 2/5] btrfs: ignore incorrect btrfs_file_extent_item::ram_bytes Qu Wenruo
2024-06-26 1:47 ` [PATCH v2 3/5] btrfs: make validate_extent_map() to catch ram_bytes mismatch Qu Wenruo
2024-06-26 1:47 ` [PATCH v2 4/5] btrfs: fix the ram_bytes assignment for truncated ordered extents Qu Wenruo
2024-06-26 1:47 ` [PATCH v2 5/5] btrfs: tree-checker: add extra ram_bytes and disk_num_bytes check Qu Wenruo
2024-06-26 11:21 ` [PATCH v2 0/5] btrfs: detect and fix the ram_bytes mismatch Filipe Manana
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.1719366258.git.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 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.