All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Foster <bfoster@redhat.com>
To: Christoph Hellwig <hch@lst.de>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH 5/2] xfs: refactor xlog_recover_buffer_pass1
Date: Tue, 28 Apr 2020 11:13:19 -0400	[thread overview]
Message-ID: <20200428151319.GE27954@bfoster> (raw)
In-Reply-To: <20200428080550.GA20138@lst.de>

On Tue, Apr 28, 2020 at 10:05:50AM +0200, Christoph Hellwig wrote:
> Split out a xlog_add_buffer_cancelled helper which does the low-level
> manipulation of the buffer cancelation table, and in that helper call
> xlog_find_buffer_cancelled instead of open coding it.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  fs/xfs/xfs_log_recover.c | 114 +++++++++++++++++++--------------------
>  1 file changed, 55 insertions(+), 59 deletions(-)
> 
> diff --git a/fs/xfs/xfs_log_recover.c b/fs/xfs/xfs_log_recover.c
> index fe4dad5b77a95..3bc61838266f1 100644
> --- a/fs/xfs/xfs_log_recover.c
> +++ b/fs/xfs/xfs_log_recover.c
...
> @@ -2045,6 +2015,32 @@ xlog_buf_readahead(
>  		xfs_buf_readahead(log->l_mp->m_ddev_targp, blkno, len, ops);
>  }
>  
> +/*
> + * Build up the table of buf cancel records so that we don't replay cancelled
> + * data in the second pass.
> + */
> +static int
> +xlog_recover_buffer_pass1(
> +	struct xlog			*log,
> +	struct xlog_recover_item	*item)
> +{
> +	struct xfs_buf_log_format	*bf = item->ri_buf[0].i_addr;
> +
> +	if (!xfs_buf_log_check_iovec(&item->ri_buf[0])) {
> +		xfs_err(log->l_mp, "bad buffer log item size (%d)",
> +				item->ri_buf[0].i_len);
> +		return -EFSCORRUPTED;
> +	}
> +
> +	if (!(bf->blf_flags & XFS_BLF_CANCEL))
> +		trace_xfs_log_recover_buf_not_cancel(log, bf);
> +	else if (xlog_add_buffer_cancelled(log, bf->blf_blkno, bf->blf_len))
> +		trace_xfs_log_recover_buf_cancel_add(log, bf);
> +	else
> +		trace_xfs_log_recover_buf_cancel_ref_inc(log, bf);

Nit, but the function call looks buried here. Also, the boolean return
seems like overkill if it's only used to control tracepoints (and
true/false for inc/ref isn't terribly intuitive anyways).

This looks cleaner to me if it's just:

	if (!XFS_BLF_CANCEL) {
		trace_xfs_log_recover_buf_not_cancel(log, bf);
		return 0;
	}

	xlog_add_buffer_cancelled(log, bf->blf_blkno, bf->blf_len);
	return 0;

... and let the helper invoke the buf_cancel tracepoints and return
void. Otherwise looks like a good cleanup to me.

Brian

> +	return 0;
> +}
> +
>  /*
>   * Perform recovery for a buffer full of inodes.  In these buffers, the only
>   * data which should be recovered is that which corresponds to the
> -- 
> 2.26.1
> 


      reply	other threads:[~2020-04-28 15:13 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-28  8:05 [PATCH 5/2] xfs: refactor xlog_recover_buffer_pass1 Christoph Hellwig
2020-04-28 15:13 ` Brian Foster [this message]

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=20200428151319.GE27954@bfoster \
    --to=bfoster@redhat.com \
    --cc=hch@lst.de \
    --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.