From: Brian Foster <bfoster@redhat.com>
To: Carlos Maiolino <cmaiolino@redhat.com>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH 2/3 V2] xfs: Add infrastructure needed for error propagation during buffer IO failure
Date: Wed, 24 May 2017 13:07:09 -0400 [thread overview]
Message-ID: <20170524170709.GB13925@bfoster.bfoster> (raw)
In-Reply-To: <20170522153220.25072-3-cmaiolino@redhat.com>
On Mon, May 22, 2017 at 05:32:19PM +0200, Carlos Maiolino wrote:
> With the current code, XFS never re-submit a failed buffer for IO,
> because the failed item in the buffer is kept in the flush locked state
> forever.
>
> To be able to resubmit an log item for IO, we need a way to mark an item
> as failed, if, for any reason the buffer which the item belonged to
> failed during writeback.
>
> Add a new log item callback to be used after an IO completion failure
> and make the needed clean ups.
>
> Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
> ---
> V2:
> - Update commit log to include a better description of why this
> patch is needed and fix spelling mistakes
> - Move xfs_buf_do_callbacks_fail() call into
> xfs_buf_iodone_callback_error, so the callbacks can be executed
> before the buffer is released, and only after it has been
> retried once
>
> fs/xfs/xfs_buf_item.c | 27 ++++++++++++++++++++++++++-
> fs/xfs/xfs_trans.h | 5 ++++-
> 2 files changed, 30 insertions(+), 2 deletions(-)
>
> diff --git a/fs/xfs/xfs_buf_item.c b/fs/xfs/xfs_buf_item.c
> index 6ac3816..8f128e3 100644
> --- a/fs/xfs/xfs_buf_item.c
> +++ b/fs/xfs/xfs_buf_item.c
> @@ -1051,6 +1051,24 @@ xfs_buf_do_callbacks(
> }
> }
>
> +STATIC void
> +xfs_buf_do_callbacks_fail(
> + struct xfs_buf *bp)
> +{
> + struct xfs_log_item *lip, *next;
> + unsigned int bflags = bp->b_flags;
> +
> + lip = bp->b_fspriv;
> + while (lip != NULL) {
> + next = lip->li_bio_list;
> +
> + if (lip->li_ops->iop_error)
> + lip->li_ops->iop_error(lip, bflags);
> +
> + lip = next;
> + }
AFAICT, this could do something like the following:
spin_lock(&ailp->xa_lock);
while (lip != NULL) {
next = lip->li_bio_list;
lip->li_flags |= XFS_LI_FAILED;
lip = next;
}
spin_unlock(&ailp->xa_lock);
... to generically and unconditionally flag the log item as failed and
avoid the need for ->iop_error(). We also need to clear XFS_LI_FAILED at
the same place we clear XFS_LI_IN_AIL (i.e., AIL removal) to ensure a
subsequent successful I/O completion updates the log item appropriately.
Then the result of this patch is that all log items are flagged as
failed on I/O error until they are ultimately removed from the AIL. We
otherwise have so far not changed behavior in any way.
Brian
> +}
> +
> static bool
> xfs_buf_iodone_callback_error(
> struct xfs_buf *bp)
> @@ -1101,6 +1119,7 @@ xfs_buf_iodone_callback_error(
>
> xfs_buf_ioerror(bp, 0);
> xfs_buf_submit(bp);
> +
> return true;
> }
>
> @@ -1120,8 +1139,14 @@ xfs_buf_iodone_callback_error(
> if ((mp->m_flags & XFS_MOUNT_UNMOUNTING) && mp->m_fail_unmount)
> goto permanent_error;
>
> - /* still a transient error, higher layers will retry */
> + /*
> + * still a transient error, run IO completion failure callbacks and
> + * let the higher layers retry the buffer.
> + * */
> xfs_buf_ioerror(bp, 0);
> +
> + /* run failure callbacks before releasing buffer */
> + xfs_buf_do_callbacks_fail(bp);
> xfs_buf_relse(bp);
> return true;
>
> diff --git a/fs/xfs/xfs_trans.h b/fs/xfs/xfs_trans.h
> index 7ae04de..7fcf48d 100644
> --- a/fs/xfs/xfs_trans.h
> +++ b/fs/xfs/xfs_trans.h
> @@ -65,10 +65,12 @@ typedef struct xfs_log_item {
>
> #define XFS_LI_IN_AIL 0x1
> #define XFS_LI_ABORTED 0x2
> +#define XFS_LI_FAILED 0x3
>
> #define XFS_LI_FLAGS \
> { XFS_LI_IN_AIL, "IN_AIL" }, \
> - { XFS_LI_ABORTED, "ABORTED" }
> + { XFS_LI_ABORTED, "ABORTED" }, \
> + { XFS_LI_FAILED, "FAILED" }
>
> struct xfs_item_ops {
> void (*iop_size)(xfs_log_item_t *, int *, int *);
> @@ -79,6 +81,7 @@ struct xfs_item_ops {
> void (*iop_unlock)(xfs_log_item_t *);
> xfs_lsn_t (*iop_committed)(xfs_log_item_t *, xfs_lsn_t);
> void (*iop_committing)(xfs_log_item_t *, xfs_lsn_t);
> + void (*iop_error)(xfs_log_item_t *, unsigned int bflags);
> };
>
> void xfs_log_item_init(struct xfs_mount *mp, struct xfs_log_item *item,
> --
> 2.9.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2017-05-24 17:07 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-22 15:32 [PATCH 0/3 V2] Resubmit items failed during writeback Carlos Maiolino
2017-05-22 15:32 ` [PATCH 1/3] xfs: use atomic operations to handle xfs_log_item flags Carlos Maiolino
2017-05-22 19:11 ` Christoph Hellwig
2017-05-23 10:35 ` Carlos Maiolino
2017-05-23 10:42 ` Carlos Maiolino
2017-05-24 17:06 ` Brian Foster
2017-06-05 12:54 ` Carlos Maiolino
2017-06-05 13:13 ` Carlos Maiolino
2017-05-22 15:32 ` [PATCH 2/3 V2] xfs: Add infrastructure needed for error propagation during buffer IO failure Carlos Maiolino
2017-05-22 19:13 ` Christoph Hellwig
2017-05-23 11:21 ` Carlos Maiolino
2017-05-24 17:07 ` Brian Foster [this message]
2017-05-26 11:51 ` Brian Foster
2017-05-22 15:32 ` [PATCH 3/3 V2] xfs: Properly retry failed inode items in case of error during buffer writeback Carlos Maiolino
2017-05-24 17:08 ` Brian Foster
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=20170524170709.GB13925@bfoster.bfoster \
--to=bfoster@redhat.com \
--cc=cmaiolino@redhat.com \
--cc=linux-xfs@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.