From: Eric Sandeen <sandeen@sandeen.net>
To: xfs@oss.sgi.com
Subject: Re: [PATCH 6/9] xfs: add "fail at unmount" error handling configuration
Date: Tue, 16 Feb 2016 11:09:22 -0600 [thread overview]
Message-ID: <56C357C2.9020506@sandeen.net> (raw)
In-Reply-To: <20160216164451.GC39655@bfoster.bfoster>
On 2/16/16 10:44 AM, Brian Foster wrote:
> On Fri, Feb 05, 2016 at 12:23:24PM +1100, Dave Chinner wrote:
>> > From: Dave Chinner <dchinner@redhat.com>
>> >
>> > If we take "retry forever" literally on metadata IO errors, we can
>> > hang an unmount retries those writes forever. This is the default
>> > behaviour, unfortunately. Add a error configuration option for this
>> > behaviour and default it to "fail" so that an unmount will trigger
>> > actual errors, a shutdown and allow the unmount to succeed. It will
>> > be noisy, though, as it will log the errors and shutdown that
>> > occurs.
>> >
>> > To do this, we need to mark the filesystem as being in the process
>> > of unmounting. Do this with a mount flag that is added at the
>> > appropriate time (i.e. before the blocking AIL sync). We also need
>> > to add this flag if mount fails after the initial phase of log
>> > recovery has been run.
>> >
>> > The config is done by a separate boolean sysfs option rather than a
>> > new fail_speed enum, as fail_at_unmount is relevant to both
>> > XFS_ERR_FAIL_NEVER and XFS_ERR_FAIL_SLOW options.
>> >
>> > Signed-off-by: Dave Chinner <dchinner@redhat.com>
>> > ---
> Similar question of scope/granularity here... why would one want to set
> this option for a particular error and not any others? In other words,
> it seems more useful as a global (or per-mount) option.
I guess my question here is higher-level than that. Why make this
(fail_at_unmount) configurable at all. When would one *want* unmount
blocked by pending failure retries?
I guess I could imagine it as sort of a safety net, "I told it to retry
for a day, and the day's not up yet, so we shouldn't stop trying
just because I said unmount!" - but that seems a bit contrived to me.
-Eric
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2016-02-16 17:09 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-05 1:23 [PATCH 0/9] xfs: configurable error behaviour Dave Chinner
2016-02-05 1:23 ` [PATCH 1/9] xfs: configurable error behaviour via sysfs Dave Chinner
2016-02-05 1:23 ` [PATCH 2/9] xfs: introduce metadata IO error class Dave Chinner
2016-02-05 1:23 ` [PATCH 3/9] xfs: add configurable error support to metadata buffers Dave Chinner
2016-02-05 1:23 ` [PATCH 4/9] xfs: introduce table-based init for error behaviours Dave Chinner
2016-02-05 1:23 ` [PATCH 5/9] xfs: add configuration of error failure speed Dave Chinner
2016-02-16 16:44 ` Brian Foster
2016-02-05 1:23 ` [PATCH 6/9] xfs: add "fail at unmount" error handling configuration Dave Chinner
2016-02-16 16:44 ` Brian Foster
2016-02-16 17:09 ` Eric Sandeen [this message]
2016-02-05 1:23 ` [PATCH 7/9] xfs: add configuration handles for specific errors Dave Chinner
2016-02-05 1:23 ` [PATCH 8/9] xfs: disable specific error configurations Dave Chinner
2016-02-16 16:45 ` Brian Foster
2016-02-05 1:23 ` [PATCH 9/9] xfs: add kmem error configuration class Dave Chinner
2016-02-13 2:52 ` [PATCH 0/9] xfs: configurable error behaviour Dave Chinner
2016-03-15 10:16 ` Carlos Maiolino
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=56C357C2.9020506@sandeen.net \
--to=sandeen@sandeen.net \
--cc=xfs@oss.sgi.com \
/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