linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: linux-xfs@vger.kernel.org
Subject: Re: [RFC PATCH] xfs: Properly retry failed dquot items in case of error during buffer writeback
Date: Fri, 13 Oct 2017 09:21:14 -0700	[thread overview]
Message-ID: <20171013162114.GP7122@magnolia> (raw)
In-Reply-To: <20170828092030.l5z2hruccr7ctvl3@hades.localdomain>

On Mon, Aug 28, 2017 at 11:20:30AM +0200, Carlos Maiolino wrote:
> Hi Darrick.
> 
> 
> > > > BTW, This patch should be applied only over branch xfs-4.14-merge, it requires
> > > > my previous patches, which are not in the master branch yet.
> > > 
> > > Looks ok, but is there an xfstests case to cover this?
> > 
> 
> No,
> 
> I still don't have a xfstests to cover it, I couldn't reproduce the problem with
> dquots yet, I'll focus more on this soon.
> 
> > > >  	if ((lip->li_flags & XFS_LI_IN_AIL) &&
> > > > -	    lip->li_lsn == qip->qli_flush_lsn) {
> > > > +	   (lip->li_lsn == qip->qli_flush_lsn) ||
> > > > +	    lip->li_flags & XFS_LI_FAILED) {
> > 
> 
> > ...come to think of it, shouldn't there be a couple extra pairs of parentheses
> > in this somewhere?...
> > 
> IIRC there is no need, && has a higher precedenc over ||, but I really don't
> mind to add an extra pair of () here.
> 
> > > >  
> > > >  		/* xfs_trans_ail_delete() drops the AIL lock. */
> > > >  		spin_lock(&ailp->xa_lock);
> > > > -		if (lip->li_lsn == qip->qli_flush_lsn)
> > > > +		if (lip->li_lsn == qip->qli_flush_lsn) {
> > > >  			xfs_trans_ail_delete(ailp, lip, SHUTDOWN_CORRUPT_INCORE);
> > > > -		else
> > > > +		} else if (lip->li_flags & XFS_LI_FAILED) {
> > > > +			xfs_clear_li_failed(lip);
> > > >  			spin_unlock(&ailp->xa_lock);
> > > > +		} else {
> > > > +			spin_unlock(&ailp->xa_lock);
> > > > +		}
> > > >  	}
> > > >  
> > > >  	/*
> > > > diff --git a/fs/xfs/xfs_dquot_item.c b/fs/xfs/xfs_dquot_item.c
> > > > index 2c7a1629e064..35fd6d71bc42 100644
> > > > --- a/fs/xfs/xfs_dquot_item.c
> > > > +++ b/fs/xfs/xfs_dquot_item.c
> > > > @@ -137,6 +137,23 @@ xfs_qm_dqunpin_wait(
> > > >  	wait_event(dqp->q_pinwait, (atomic_read(&dqp->q_pincount) == 0));
> > > >  }
> > > >  
> > > > +/*
> > > > + * Callback used to mark a buffer with XFS_LI_FAILED when items in the buffer
> > > > + * have been failed during writeback
> > > > + *
> > > > + * this informs the AIL that the dquot is already flush locked on the next push,
> > > > + * and acquires a hold on the buffer to ensure that it isn't reclaimed before
> > > > + * dirty data makes it to disk.
> > > > + */
> > > > +STATIC void
> > > > +xfs_dquot_item_error(
> > > > +	struct xfs_log_item	*lip,
> > > > +	struct xfs_buf		*bp)
> > > > +{
> > > > +	ASSERT(XFS_DQ_IS_LOCKED(DQUOT_ITEM(lip)->qli_item));
> > 
> > ...and isn't this qli_dquot, not qli_item?
> > 
> 
> Yup, you are right.
> 
> > (Does this compile at all?)
> > 
> 
> Yes, it compiled the way it was :P
> 
> I'll wait for some extra comments here, before submitting a non-RFC patch, and
> will think about how can I reproduce it on xfstests, maybe filling the
> filesystem and then playing with quotas.

Has there been a rework of this patch?

--D

> 
> Thanks for the review Darrick.
> 
> Cheers.
> 
> -- 
> Carlos
> --
> 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

  reply	other threads:[~2017-10-13 16:21 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-25 12:07 [RFC PATCH] xfs: Properly retry failed dquot items in case of error during buffer writeback Carlos Maiolino
2017-08-25 17:04 ` Darrick J. Wong
2017-08-25 21:57   ` Darrick J. Wong
2017-08-28  9:20     ` Carlos Maiolino
2017-10-13 16:21       ` Darrick J. Wong [this message]
2017-11-20 15:03         ` Carlos Maiolino
2017-10-16  3:05       ` Hou Tao
2017-10-16 18:49         ` Darrick J. Wong
2017-11-20 15:04         ` 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=20171013162114.GP7122@magnolia \
    --to=darrick.wong@oracle.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).