From: Brian Foster <bfoster@redhat.com>
To: Carlos Maiolino <cmaiolino@redhat.com>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH 2/2] xfs: Properly retry failed inode items in case of error during buffer writeback
Date: Thu, 11 May 2017 13:08:05 -0400 [thread overview]
Message-ID: <20170511170805.GB14148@localhost.localdomain> (raw)
In-Reply-To: <20170511135733.21765-3-cmaiolino@redhat.com>
On Thu, May 11, 2017 at 03:57:33PM +0200, Carlos Maiolino wrote:
> When a buffer has been failed during writeback, the inode items into it
> are kept flush locked, and are never resubmitted due the flush lock, so,
> if any buffer fails to be written, the items in AIL are never written to
> disk and never unlocked.
>
> This causes a filesystem to be unmountable due these items flush locked
> in AIL, but this also causes the items in AIL to never be written back,
> even when the IO device comes back to normal.
>
> I've been testing this patch with a DM-thin device, creating a
> filesystem larger than the real device.
>
> When writing enough data to fill the DM-thin device, XFS receives ENOSPC
> errors from the device, and keep spinning on xfsaild (when 'retry
> forever' configuration is set).
>
> At this point, the filesystem is unmountable because of the flush locked
> items in AIL, but worse, the items in AIL are never retried at all
> (once xfs_inode_item_push() will skip the items that are flush locked),
> even if the underlying DM-thin device is expanded to the proper size.
>
> This patch fixes both cases, retrying any item that has been failed
> previously, using the infra-structure provided by the previous patch.
>
> Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
> ---
>
> This same problem is also possible in dquot code, but the fix is almost
> identical.
>
> I am not submitting a fix for dquot yet to avoid the need to create VX for both
> patches, once we agree with the solution, I'll submit a fix to dquot.
>
> fs/xfs/xfs_inode_item.c | 54 ++++++++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 53 insertions(+), 1 deletion(-)
>
> diff --git a/fs/xfs/xfs_inode_item.c b/fs/xfs/xfs_inode_item.c
> index 08cb7d1..583fa9e 100644
> --- a/fs/xfs/xfs_inode_item.c
> +++ b/fs/xfs/xfs_inode_item.c
> @@ -475,6 +475,21 @@ xfs_inode_item_unpin(
> wake_up_bit(&ip->i_flags, __XFS_IPINNED_BIT);
> }
>
> +STATIC void
> +xfs_inode_item_error(
> + struct xfs_log_item *lip,
> + unsigned int bflags)
> +{
> +
> + /*
> + * The buffer writeback containing this inode has been failed
> + * mark it as failed and unlock the flush lock, so it can be retried
> + * again
> + */
> + if (bflags & XBF_WRITE_FAIL)
> + lip->li_flags |= XFS_LI_FAILED;
> +}
> +
> STATIC uint
> xfs_inode_item_push(
> struct xfs_log_item *lip,
> @@ -517,8 +532,44 @@ xfs_inode_item_push(
> * the AIL.
> */
> if (!xfs_iflock_nowait(ip)) {
> + if (lip->li_flags & XFS_LI_FAILED) {
> +
> + struct xfs_dinode *dip;
> + struct xfs_log_item *next;
> + int error;
> +
> + error = xfs_imap_to_bp(ip->i_mount, NULL, &ip->i_imap,
> + &dip, &bp, XBF_TRYLOCK, 0);
> +
> + if (error) {
> + rval = XFS_ITEM_FLUSHING;
> + goto out_unlock;
> + }
> +
> + if (!(bp->b_flags & XBF_WRITE_FAIL)) {
> + rval = XFS_ITEM_FLUSHING;
> + xfs_buf_relse(bp);
> + goto out_unlock;
> + }
> +
> + while (lip != NULL) {
> + next = lip->li_bio_list;
> +
> + if (lip->li_flags & XFS_LI_FAILED)
> + lip->li_flags &= XFS_LI_FAILED;
Eric already pointed out that you probably intend to clear the flag
here..?
> + lip = next;
> + }
This whole hunk might be better off in a helper function (with the
comment Eric suggested as well).
Those points and the ->iop_error() thing aside, this otherwise seems Ok
to me.
Brian
> +
> + if (!xfs_buf_delwri_queue(bp, buffer_list))
> + rval = XFS_ITEM_FLUSHING;
> +
> + xfs_buf_relse(bp);
> + goto out_unlock;
> + }
> +
> rval = XFS_ITEM_FLUSHING;
> goto out_unlock;
> +
> }
>
> ASSERT(iip->ili_fields != 0 || XFS_FORCED_SHUTDOWN(ip->i_mount));
> @@ -622,7 +673,8 @@ static const struct xfs_item_ops xfs_inode_item_ops = {
> .iop_unlock = xfs_inode_item_unlock,
> .iop_committed = xfs_inode_item_committed,
> .iop_push = xfs_inode_item_push,
> - .iop_committing = xfs_inode_item_committing
> + .iop_committing = xfs_inode_item_committing,
> + .iop_error = xfs_inode_item_error
> };
>
>
> --
> 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-11 17:08 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-11 13:57 [PATCH 0/2] Resubmit items failed during writeback Carlos Maiolino
2017-05-11 13:57 ` [PATCH 1/2] xfs: Add infrastructure needed for error propagation during buffer IO failure Carlos Maiolino
2017-05-11 16:51 ` Brian Foster
2017-05-12 8:41 ` Carlos Maiolino
2017-05-12 11:37 ` Brian Foster
2017-05-11 13:57 ` [PATCH 2/2] xfs: Properly retry failed inode items in case of error during buffer writeback Carlos Maiolino
2017-05-11 15:32 ` Eric Sandeen
2017-05-12 8:19 ` Carlos Maiolino
2017-05-11 17:08 ` Brian Foster [this message]
2017-05-12 8:21 ` Carlos Maiolino
2017-05-12 11:37 ` Brian Foster
2017-05-17 11:47 ` Carlos Maiolino
2017-05-17 0:57 ` Dave Chinner
2017-05-17 10:41 ` Carlos Maiolino
2017-05-19 0:22 ` Dave Chinner
2017-05-19 11:27 ` Brian Foster
2017-05-19 23:39 ` Dave Chinner
2017-05-20 11:46 ` Brian Foster
2017-05-21 23:19 ` Dave Chinner
2017-05-22 12:51 ` Brian Foster
2017-05-23 11:23 ` Dave Chinner
2017-05-23 16:22 ` Brian Foster
2017-05-24 1:06 ` Dave Chinner
2017-05-24 12:42 ` Brian Foster
2017-05-24 13:26 ` Carlos Maiolino
2017-05-24 17:08 ` Brian Foster
-- strict thread matches above, loose matches on Subject: below --
2017-06-16 10:54 [PATCH 0/2 V4] Resubmit items failed during writeback Carlos Maiolino
2017-06-16 10:54 ` [PATCH 2/2] xfs: Properly retry failed inode items in case of error during buffer writeback Carlos Maiolino
2017-06-16 11:06 ` Carlos Maiolino
2017-06-16 18:35 ` Luis R. Rodriguez
2017-06-16 19:24 ` Darrick J. Wong
2017-06-16 19:37 ` Luis R. Rodriguez
2017-06-16 19:45 ` Eric Sandeen
2017-06-19 10:59 ` Brian Foster
2017-06-20 16:52 ` Luis R. Rodriguez
2017-06-20 17:20 ` Brian Foster
2017-06-20 18:05 ` Luis R. Rodriguez
2017-06-21 10:10 ` Brian Foster
2017-06-21 15:25 ` Luis R. Rodriguez
2017-06-20 18:38 ` Luis R. Rodriguez
2017-06-20 7:01 ` Carlos Maiolino
2017-06-20 16:24 ` Luis R. Rodriguez
2017-06-21 11:51 ` Carlos Maiolino
2017-06-19 13:49 ` Brian Foster
2017-06-19 15:09 ` 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=20170511170805.GB14148@localhost.localdomain \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).