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

  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 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.