linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH 03/19] xfs: refactor log recovery item dispatch for pass2 readhead functions
Date: Tue, 28 Apr 2020 13:54:24 -0700	[thread overview]
Message-ID: <20200428205424.GG6742@magnolia> (raw)
In-Reply-To: <20200425181929.GB16698@infradead.org>

On Sat, Apr 25, 2020 at 11:19:29AM -0700, Christoph Hellwig wrote:
> On Tue, Apr 21, 2020 at 07:06:21PM -0700, Darrick J. Wong wrote:
> >  typedef enum xlog_recover_reorder (*xlog_recover_reorder_fn)(
> >  		struct xlog_recover_item *item);
> > +typedef void (*xlog_recover_ra_pass2_fn)(struct xlog *log,
> > +		struct xlog_recover_item *item);
> 
> Same comment for this one - or the other two following.

<nod> I'll skip the typedefs.

> > +/*
> > + * This structure is used during recovery to record the buf log items which
> > + * have been canceled and should not be replayed.
> > + */
> > +struct xfs_buf_cancel {
> > +	xfs_daddr_t		bc_blkno;
> > +	uint			bc_len;
> > +	int			bc_refcount;
> > +	struct list_head	bc_list;
> > +};
> > +
> > +struct xfs_buf_cancel *xlog_peek_buffer_cancelled(struct xlog *log,
> > +		xfs_daddr_t blkno, uint len, unsigned short flags);
> 
> None of the callers moved in this patch even needs the xfs_buf_cancel
> structure, it just uses the return value as a boolean.  I think they
> all should be switched to use xlog_check_buffer_cancelled instead, which
> means that struct xfs_buf_cancel and xlog_peek_buffer_cancelled can stay
> private in xfs_log_recovery.c (and later xfs_buf_item.c).

They now all use your new xlog_buf_readahead function.

> > +STATIC void
> > +xlog_recover_buffer_ra_pass2(
> > +	struct xlog                     *log,
> > +	struct xlog_recover_item        *item)
> > +{
> > +	struct xfs_buf_log_format	*buf_f = item->ri_buf[0].i_addr;
> > +	struct xfs_mount		*mp = log->l_mp;
> > +
> > +	if (xlog_peek_buffer_cancelled(log, buf_f->blf_blkno,
> > +			buf_f->blf_len, buf_f->blf_flags)) {
> > +		return;
> > +	}
> > +
> > +	xfs_buf_readahead(mp->m_ddev_targp, buf_f->blf_blkno,
> > +				buf_f->blf_len, NULL);
> 
> Why not:
> 
> 	if (!xlog_peek_buffer_cancelled(log, buf_f->blf_blkno,
> 			buf_f->blf_len, buf_f->blf_flags)) {
> 		xfs_buf_readahead(mp->m_ddev_targp, buf_f->blf_blkno,
> 				buf_f->blf_len, NULL);
> 	}
> 
> > +STATIC void
> > +xlog_recover_dquot_ra_pass2(
> > +	struct xlog			*log,
> > +	struct xlog_recover_item	*item)
> > +{
> > +	struct xfs_mount	*mp = log->l_mp;
> > +	struct xfs_disk_dquot	*recddq;
> > +	struct xfs_dq_logformat	*dq_f;
> > +	uint			type;
> > +	int			len;
> > +
> > +
> > +	if (mp->m_qflags == 0)
> 
> Double empty line above.
> 
> > +	if (xlog_peek_buffer_cancelled(log, dq_f->qlf_blkno, len, 0))
> > +		return;
> > +
> > +	xfs_buf_readahead(mp->m_ddev_targp, dq_f->qlf_blkno, len,
> > +			  &xfs_dquot_buf_ra_ops);
> 
> Same comment as above, no real need for the early return here.
> 
> > +	if (xlog_peek_buffer_cancelled(log, ilfp->ilf_blkno, ilfp->ilf_len, 0))
> > +		return;
> > +
> > +	xfs_buf_readahead(mp->m_ddev_targp, ilfp->ilf_blkno,
> > +				ilfp->ilf_len, &xfs_inode_buf_ra_ops);
> 
> Here again.

Changed to xlog_buf_readahead.

> 
> > -	unsigned short			flags)
> > +	unsigned short		flags)
> 
> Spurious whitespace change.
> 
> >  		case XLOG_RECOVER_PASS2:
> > -			xlog_recover_ra_pass2(log, item);
> > +			if (item->ri_type && item->ri_type->ra_pass2_fn)
> > +				item->ri_type->ra_pass2_fn(log, item);
> 
> Shouldn't we ensure eatly on that we always have a valid ->ri_type?

Item sorting will bail out on unrecognized log item types, in which case
we will discard the transaction (and all its items) and abort the mount,
right?  That should suffice to ensure that we always have a valid
ri_type long before we get to starting readahead for pass 2.

--D

  reply	other threads:[~2020-04-28 20:54 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-22  2:06 [PATCH 00/19] xfs: refactor log recovery Darrick J. Wong
2020-04-22  2:06 ` [PATCH 01/19] xfs: complain when we don't recognize the log item type Darrick J. Wong
2020-04-22 16:17   ` Brian Foster
2020-04-25 17:42   ` Christoph Hellwig
2020-04-27 17:55     ` Darrick J. Wong
2020-04-22  2:06 ` [PATCH 02/19] xfs: refactor log recovery item sorting into a generic dispatch structure Darrick J. Wong
2020-04-25 18:13   ` Christoph Hellwig
2020-04-27 22:04     ` Darrick J. Wong
2020-04-28  5:11       ` Christoph Hellwig
2020-04-28 20:46         ` Darrick J. Wong
2020-04-22  2:06 ` [PATCH 03/19] xfs: refactor log recovery item dispatch for pass2 readhead functions Darrick J. Wong
2020-04-25 18:19   ` Christoph Hellwig
2020-04-28 20:54     ` Darrick J. Wong [this message]
2020-04-29  6:07       ` Christoph Hellwig
2020-04-22  2:06 ` [PATCH 04/19] xfs: refactor log recovery item dispatch for pass1 commit functions Darrick J. Wong
2020-04-25 18:20   ` Christoph Hellwig
2020-04-22  2:06 ` [PATCH 05/19] xfs: refactor log recovery buffer item dispatch for pass2 " Darrick J. Wong
2020-04-22  2:06 ` [PATCH 06/19] xfs: refactor log recovery inode " Darrick J. Wong
2020-04-22  2:06 ` [PATCH 07/19] xfs: refactor log recovery intent " Darrick J. Wong
2020-04-25 18:24   ` Christoph Hellwig
2020-04-28 22:42     ` Darrick J. Wong
2020-04-22  2:06 ` [PATCH 08/19] xfs: refactor log recovery dquot " Darrick J. Wong
2020-04-22  2:07 ` [PATCH 09/19] xfs: refactor log recovery icreate " Darrick J. Wong
2020-04-22  2:07 ` [PATCH 10/19] xfs: refactor log recovery quotaoff " Darrick J. Wong
2020-04-22  2:07 ` [PATCH 11/19] xfs: refactor EFI log item recovery dispatch Darrick J. Wong
2020-04-25 18:28   ` Christoph Hellwig
2020-04-28 22:41     ` Darrick J. Wong
2020-04-28 23:45       ` Darrick J. Wong
2020-04-29  7:09         ` Christoph Hellwig
2020-04-29  7:18           ` Christoph Hellwig
2020-04-29 14:20           ` Darrick J. Wong
2020-04-22  2:07 ` [PATCH 12/19] xfs: refactor RUI " Darrick J. Wong
2020-04-25 18:28   ` Christoph Hellwig
2020-04-28 22:40     ` Darrick J. Wong
2020-04-22  2:07 ` [PATCH 13/19] xfs: refactor CUI " Darrick J. Wong
2020-04-22  2:07 ` [PATCH 14/19] xfs: refactor BUI " Darrick J. Wong
2020-04-22  2:07 ` [PATCH 15/19] xfs: refactor releasing finished intents during log recovery Darrick J. Wong
2020-04-25 18:34   ` Christoph Hellwig
2020-04-28 22:40     ` Darrick J. Wong
2020-04-22  2:07 ` [PATCH 16/19] xfs: refactor adding recovered intent items to the log Darrick J. Wong
2020-04-25 18:34   ` Christoph Hellwig
2020-04-22  2:07 ` [PATCH 17/19] xfs: hoist the ail unlock/lock cycle when cancelling intents during recovery Darrick J. Wong
2020-04-25 18:35   ` Christoph Hellwig
2020-04-22  2:07 ` [PATCH 18/19] xfs: remove xlog_item_is_intent Darrick J. Wong
2020-04-22  2:08 ` [PATCH 19/19] xfs: move xlog_recover_intent_pass2 up in the file Darrick J. Wong
2020-04-25 18:36   ` Christoph Hellwig
2020-04-28 22:38     ` Darrick J. Wong
2020-04-22 16:18 ` [PATCH 00/19] xfs: refactor log recovery Brian Foster
2020-04-28  6:12   ` Christoph Hellwig
2020-04-28 12:43     ` Brian Foster
2020-04-28 22:34       ` Darrick J. Wong
2020-04-29  6:09         ` Christoph Hellwig
2020-04-29 11:52         ` Brian Foster
2020-04-29 14:22           ` Darrick J. Wong
2020-04-28  6:22 ` Christoph Hellwig
2020-04-28 22:28   ` Darrick J. Wong

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=20200428205424.GG6742@magnolia \
    --to=darrick.wong@oracle.com \
    --cc=hch@infradead.org \
    --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).