From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH 0/3] btrfs: introduce 3 debug sysfs interface to tweak the error handling behavior
Date: Sun, 24 Sep 2023 15:44:11 +0930 [thread overview]
Message-ID: <cover.1695535440.git.wqu@suse.com> (raw)
During a very interesting (and weird) debugging session, it turns out
that btrfs will ignore a lot of write errors until we hit some critical
location, then btrfs started reacting, normally by aborting the
transaction.
This can be problematic for developers
As sometimes we want to catch the earlies sign, continuing without any
obvious errors (other than kernel error messages) can make debugging
much harder.
On the other hand, I totally understand if just a single sector failed
to be write and we mark the whole fs read-only, it can be super
frustrating for regular end users, thus we can not make it the default
behavior.
So this patchset would introduce the following sysfs entries under
/sys/fs/btrfs/<uuid>/debug/:
- allow_backup_super_failure
RW, binary (0 or 1), determines if btrfs would tolerace backup super
blocks writeback failure.
If set to 1 and a failure is hit, btrfs would treat backup super
blocks writeback failure as critical (the same level as primary super
blocks).
The default value is 1, so the default behavior is not changed.
NOTE: this doesn't mean such failure would immediately lead to
trasaction abort. Check `super_failure_tolerance` for more details.
- allow_data_failure
RW, binary (0 or 1), determines if btrfs would tolerace data sectors
writeback failure.
If set to 1 and a failure is hit, btrfs would flip read-only
immediately.
The default value is 1, so the default behavior is not changed.
- super_failure_tolerance
RW, s8, determines the tolerance for devices super blocks writeback.
Btrfs allows "nr_devices - 1" devices to fail their super blocks
writeback. This means if we have 5 disks, btrfs allows 4 to fail their
super block writeback.
If the value >= 0, the value itself would be the tolerance.
If the value < 0, nr_devices + the value would be the tolerance.
If value + nr_devices is still minus, btrfs would allow all devices
to fail their super blocks writeback (aka, very dangerous)
The default value is -1, to match the existing behavior.
There would be another one for btrfs bio layer, but I have found
something weird in the code, thus it would only be introduced after I
solved the problem there, meanwhile we can discuss on the usefulness of
this patchset.
Qu Wenruo (3):
btrfs: introduce allow_backup_super_failure sysfs interface
btrfs: introduce super_failure_tolerance sysfs interface
btrfs: introduce allow_data_failure sysfs interface
fs/btrfs/disk-io.c | 35 +++++++++++++---
fs/btrfs/extent_io.c | 8 +++-
fs/btrfs/fs.h | 23 ++++++++++
fs/btrfs/inode.c | 9 +++-
fs/btrfs/sysfs.c | 99 ++++++++++++++++++++++++++++++++++++++++++++
5 files changed, 167 insertions(+), 7 deletions(-)
--
2.42.0
next reply other threads:[~2023-09-24 6:14 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-24 6:14 Qu Wenruo [this message]
2023-09-24 6:14 ` [PATCH 1/3] btrfs: introduce allow_backup_super_failure sysfs interface Qu Wenruo
2023-09-24 6:14 ` [PATCH 2/3] btrfs: introduce super_failure_tolerance " Qu Wenruo
2023-09-24 6:14 ` [PATCH 3/3] btrfs: introduce allow_data_failure " Qu Wenruo
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.1695535440.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.