From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH v2 0/7] btrfs: scrub: refine the error messages output frequency
Date: Wed, 20 Mar 2024 14:24:50 +1030 [thread overview]
Message-ID: <cover.1710906371.git.wqu@suse.com> (raw)
[CHANGELOG]
v2:
- Remove the patch that reworks the output message format
That change still needs quite some debates, as it's a big trade-off
between easy to read for a single line and easy to batch floods of
multiple lines.
(Considering my personal experience, I would even recommend to go CSV
like output, as all the real-world reports are floods of such error
messages, never a single one)
- Split the ratelimit work into its own patch
The last one
- Address the feedbacks from the mailing list
[BACKGROUND]
During some support sessions, I found older kernels are always report
very unuseful scrub error messages like:
BTRFS error (device dm-0): bdev /dev/mapper/sys-rootlv errs: wr 0, rd 0, flush 0, corrupt 2823, gen 0
BTRFS error (device dm-0): unable to fixup (regular) error at logical 1563504640 on dev /dev/mapper/sys-rootlv
BTRFS error (device dm-0): bdev /dev/mapper/sys-rootlv errs: wr 0, rd 0, flush 0, corrupt 2824, gen 0
BTRFS error (device dm-0): unable to fixup (regular) error at logical 1579016192 on dev /dev/mapper/sys-rootlv
There are two problems:
- No proper details about the corruption
No metadata or data indication, nor the filename or the tree id.
Even the involved kernel (and newer kernels after the scrub rework)
has the ability to do backref walk and find out the file path or the
tree backref.
My guess is, for data sometimes the corrupted sector is no longer
referred by any data extent.
- Too noisy and useless error message from
btrfs_dev_stat_inc_and_print()
I'd argue we should not output any error message just for
btrfs_dev_stat_inc_and_print().
After the series, the error message would look like this:
BTRFS info (device dm-3): scrub: started on devid 1
BTRFS warning (device dm-3): checksum error at logical 13647872 on dev /dev/mapper/test-scratch1, physical 13647872, root 5, inode 257, offset 16384, path: file1
BTRFS info (device dm-3): scrub: finished on devid 1 with status: 0
This involves the following enhancement:
- Single line
And we ensure we output at least one line for the error we hit.
No more unrelated btrfs_dev_stat_inc_and_print() output.
- Proper fall backs
We have the following different fall back options
* Repaired
Just a line of something repaired for logical/physical address.
* Detailed data info
Including the following elements (if possible), and if higher
priority ones can not be fetched, it would be skipped and try
lower priority items:
+ file path (can have multiple ones)
+ root/inode number and offset
+ logical/physical address (always output)
* Detaile metadata info
The priority list is:
+ root ref/level
+ logical/physical address (always output)
For the worst case of data corruption, we would still have some like:
BTRFS warning (device dm-2): checksum error at data, logical 13647872 on dev /dev/mapper/test-scratch1 physical 13647872
And similar ones for metadata:
BTRFS warning (device dm-2): checksum error at metadata, logical 13647872 on dev /dev/mapper/test-scratch1 physical 13647872
[PATCHSET STRUCTURE]
The first patch is fixing a regression in the error message, which leads
to bad logical/physical bytenr.
The second one would reduce the log level for
btrfs_dev_stat_inc_and_print().
Patch 3~4 are cleanups to remove unnecessary parameters.
Patch 5 remove the unnecessary output for nlink and reduce one inode
item lookup.
Patch 6 ensures we get at least one error message output before
ratelimit, and if we failed to output anything, output a fallback error
message.
The final patch would rework how we do rate limits, and use the same way
(btrfs_*_rl() helpers) to do rate limits.
Qu Wenruo (7):
btrfs: scrub: fix incorrectly reported logical/physical address
btrfs: reduce the log level for btrfs_dev_stat_inc_and_print()
btrfs: scrub: remove unused is_super parameter from
scrub_print_common_warning()
btrfs: scrub: remove unnecessary dev/physical lookup for
scrub_stripe_report_errors()
btrfs: scrub: simplify the inode iteration output
btrfs: scrub: ensure we output at least one error message for
unrepaired corruption
btrfs: scrub: use generic ratelimit helpers to output error messages
fs/btrfs/scrub.c | 142 ++++++++++++---------------------------------
fs/btrfs/volumes.c | 2 +-
2 files changed, 39 insertions(+), 105 deletions(-)
--
2.44.0
next reply other threads:[~2024-03-20 3:55 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-20 3:54 Qu Wenruo [this message]
2024-03-20 3:54 ` [PATCH v2 1/7] btrfs: scrub: fix incorrectly reported logical/physical address Qu Wenruo
2024-03-20 3:54 ` [PATCH v2 2/7] btrfs: reduce the log level for btrfs_dev_stat_inc_and_print() Qu Wenruo
2024-04-04 20:26 ` David Sterba
2024-04-04 22:02 ` Qu Wenruo
2024-03-20 3:54 ` [PATCH v2 3/7] btrfs: scrub: remove unused is_super parameter from scrub_print_common_warning() Qu Wenruo
2024-03-20 3:54 ` [PATCH v2 4/7] btrfs: scrub: remove unnecessary dev/physical lookup for scrub_stripe_report_errors() Qu Wenruo
2024-03-20 13:09 ` Filipe Manana
2024-03-20 3:54 ` [PATCH v2 5/7] btrfs: scrub: simplify the inode iteration output Qu Wenruo
2024-03-20 3:54 ` [PATCH v2 6/7] btrfs: scrub: ensure we output at least one error message for unrepaired corruption Qu Wenruo
2024-03-20 13:30 ` Filipe Manana
2024-03-20 3:54 ` [PATCH v2 7/7] btrfs: scrub: use generic ratelimit helpers to output error messages Qu Wenruo
2024-03-20 13:33 ` 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.1710906371.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.