From: Brian Foster <bfoster@redhat.com>
To: Carlos Maiolino <cmaiolino@redhat.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 0/7] Configurable error behavior [V3]
Date: Thu, 5 May 2016 10:11:07 -0400 [thread overview]
Message-ID: <20160505141107.GG1231@bfoster.bfoster> (raw)
In-Reply-To: <1462376600-8617-1-git-send-email-cmaiolino@redhat.com>
On Wed, May 04, 2016 at 05:43:13PM +0200, Carlos Maiolino wrote:
> This is the new revision of this patchset, according to last comments.
>
> This patchset is aimed to implement a configurable error behavior in XFS, and
> most of the design has been done by Dave, so, that's why I kept his signed-off
> in the patches.
>
> This new revision has the detailed changelog written on each patch, but the
> major changes are:
>
> - Detailed changelog by-patch and description fixed to become
> (hopefuly) more clear
> - kept fail_at_unmount as a sysfs attribute
>
>
> Regarding fail_at_unmount, I left it almost exactly as Dave's design, giving his
> comments on the last revision, although, I still think there is no need to keep
> it as a per-error granularity, so, I was wondering if a single, global option in
> /sys/fs/xfs/<dev>/error/fail_at_unmount wouldn't suffice, but, this will require
> a new place to store the value inside kernel, instead of keeping it inside
> struct xfs_error_cfg, or maybe use the same structure but use it outside of the
> m_error_cfg array?
>
I agree with regard to the granularity of fail_at_unmount. This was
brought up previously:
http://oss.sgi.com/archives/xfs/2016-02/msg00558.html
... and I haven't heard a use case for per-error granularity.
I suggest just to pull it out of the error classification stuff entirely
and place it under xfs_mount. E.g., at the same level as "fail_writes"
(but not a DEBUG mode only option).
I'm also wondering whether we need more mechanism for the
fail_at_unmount behavior. For example, instead of defining
XFS_MOUNT_UNMOUNTING, could we just call a function that resets
max_retries (of each class) to 0 in the unmount path? Then maybe call
the mount tunable retry_on_unmount or something like that. Thoughts?
Brian
> First 6 patches are ready, the fail_at_unmount one, need to be re-worked if we
> want it in a less granular way, but until now I don't think we reached any
> decision about how it should be implemented.
>
> fs/xfs/xfs_buf.h | 22 ++++
> fs/xfs/xfs_buf_item.c | 126 ++++++++++++++--------
> fs/xfs/xfs_mount.c | 19 +++-
> fs/xfs/xfs_mount.h | 32 ++++++
> fs/xfs/xfs_sysfs.c | 283 +++++++++++++++++++++++++++++++++++++++++++++++++-
> fs/xfs/xfs_sysfs.h | 3 +
> 6 files changed, 437 insertions(+), 48 deletions(-)
>
> --
> 2.4.11
>
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2016-05-05 14:11 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-04 15:43 [PATCH 0/7] Configurable error behavior [V3] Carlos Maiolino
2016-05-04 15:43 ` [PATCH 1/7] xfs: configurable error behavior via sysfs Carlos Maiolino
2016-05-05 14:10 ` Brian Foster
2016-05-04 15:43 ` [PATCH 2/7] xfs: introduce metadata IO error class Carlos Maiolino
2016-05-05 14:10 ` Brian Foster
2016-05-04 15:43 ` [PATCH 3/7] xfs: add configurable error support to metadata buffers Carlos Maiolino
2016-05-05 14:10 ` Brian Foster
2016-05-04 15:43 ` [PATCH 4/7] xfs: introduce table-based init for error behaviors Carlos Maiolino
2016-05-05 14:10 ` Brian Foster
2016-05-04 15:43 ` [PATCH 5/7] xfs: add configuration of error failure speed Carlos Maiolino
2016-05-05 14:10 ` Brian Foster
2016-05-06 0:04 ` Dave Chinner
2016-05-06 10:59 ` Carlos Maiolino
2016-05-04 15:43 ` [PATCH 6/7] xfs: add configuration handlers for specific errors Carlos Maiolino
2016-05-05 14:11 ` Brian Foster
2016-05-05 23:57 ` Dave Chinner
2016-05-04 15:43 ` [PATCH 7/7] xfs: add "fail at unmount" error handling configuration Carlos Maiolino
2016-05-05 14:11 ` Brian Foster [this message]
2016-05-05 14:37 ` [PATCH 0/7] Configurable error behavior [V3] Carlos Maiolino
2016-05-05 15:18 ` Brian Foster
2016-05-05 23:49 ` Dave Chinner
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=20160505141107.GG1231@bfoster.bfoster \
--to=bfoster@redhat.com \
--cc=cmaiolino@redhat.com \
--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.