All of lore.kernel.org
 help / color / mirror / Atom feed
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


             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.