From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Christoph Hellwig <hch@lst.de>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH 4/8] xfs: don't log the inode in xfs_fs_map_blocks if it wasn't modified
Date: Mon, 28 Oct 2019 09:12:45 -0700 [thread overview]
Message-ID: <20191028161245.GD15222@magnolia> (raw)
In-Reply-To: <20191025150336.19411-5-hch@lst.de>
On Fri, Oct 25, 2019 at 05:03:32PM +0200, Christoph Hellwig wrote:
> Even if we are asked for a write layout there is no point in logging
> the inode unless we actually modified it in some way.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> fs/xfs/xfs_pnfs.c | 43 +++++++++++++++++++------------------------
> 1 file changed, 19 insertions(+), 24 deletions(-)
>
> diff --git a/fs/xfs/xfs_pnfs.c b/fs/xfs/xfs_pnfs.c
> index 9c96493be9e0..fa90c6334c7c 100644
> --- a/fs/xfs/xfs_pnfs.c
> +++ b/fs/xfs/xfs_pnfs.c
> @@ -147,32 +147,27 @@ xfs_fs_map_blocks(
> if (error)
> goto out_unlock;
>
> - if (write) {
> - enum xfs_prealloc_flags flags = 0;
> -
> + if (write &&
> + (!nimaps || imap.br_startblock == HOLESTARTBLOCK)) {
> ASSERT(imap.br_startblock != DELAYSTARTBLOCK);
The change in code flow makes this assert rather useless, I think, since
we only end up in this branch if we have a write and a hole. If the
condition that it checks is important (and it seems to be?) then it
ought to be hoisted up a level and turned into:
ASSERT(!write || !nimaps || imap.br_startblock != DELAYSTARTBLOCK);
Right?
Otherwise looks ok.
--D
>
> - if (!nimaps || imap.br_startblock == HOLESTARTBLOCK) {
> - /*
> - * xfs_iomap_write_direct() expects to take ownership of
> - * the shared ilock.
> - */
> - xfs_ilock(ip, XFS_ILOCK_SHARED);
> - error = xfs_iomap_write_direct(ip, offset, length,
> - &imap, nimaps);
> - if (error)
> - goto out_unlock;
> -
> - /*
> - * Ensure the next transaction is committed
> - * synchronously so that the blocks allocated and
> - * handed out to the client are guaranteed to be
> - * present even after a server crash.
> - */
> - flags |= XFS_PREALLOC_SET | XFS_PREALLOC_SYNC;
> - }
> -
> - error = xfs_update_prealloc_flags(ip, flags);
> + /*
> + * xfs_iomap_write_direct() expects to take ownership of the
> + * shared ilock.
> + */
> + xfs_ilock(ip, XFS_ILOCK_SHARED);
> + error = xfs_iomap_write_direct(ip, offset, length, &imap,
> + nimaps);
> + if (error)
> + goto out_unlock;
> +
> + /*
> + * Ensure the next transaction is committed synchronously so
> + * that the blocks allocated and handed out to the client are
> + * guaranteed to be present even after a server crash.
> + */
> + error = xfs_update_prealloc_flags(ip,
> + XFS_PREALLOC_SET | XFS_PREALLOC_SYNC);
> if (error)
> goto out_unlock;
> }
> --
> 2.20.1
>
next prev parent reply other threads:[~2019-10-28 16:12 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-25 15:03 a few iomap / bmap cleanups Christoph Hellwig
2019-10-25 15:03 ` [PATCH 1/8] xfs: simplify xfs_iomap_eof_align_last_fsb Christoph Hellwig
2019-10-28 15:55 ` Darrick J. Wong
2019-10-25 15:03 ` [PATCH 2/8] xfs: mark xfs_eof_alignment static Christoph Hellwig
2019-10-28 15:55 ` Darrick J. Wong
2019-10-25 15:03 ` [PATCH 3/8] xfs: remove the extsize argument to xfs_eof_alignment Christoph Hellwig
2019-10-28 16:06 ` Darrick J. Wong
2019-10-29 7:57 ` Christoph Hellwig
2019-10-25 15:03 ` [PATCH 4/8] xfs: don't log the inode in xfs_fs_map_blocks if it wasn't modified Christoph Hellwig
2019-10-28 16:12 ` Darrick J. Wong [this message]
2019-10-29 7:58 ` Christoph Hellwig
2019-10-30 16:12 ` Darrick J. Wong
2019-10-30 17:56 ` Christoph Hellwig
2019-10-25 15:03 ` [PATCH 5/8] xfs: simplify the xfs_iomap_write_direct calling conventions Christoph Hellwig
2019-10-28 16:25 ` Darrick J. Wong
2019-10-25 15:03 ` [PATCH 6/8] xfs: refactor xfs_bmapi_allocate Christoph Hellwig
2019-10-28 16:29 ` Darrick J. Wong
2019-10-25 15:03 ` [PATCH 7/8] xfs: move extent zeroing to xfs_bmapi_allocate Christoph Hellwig
2019-10-28 16:31 ` Darrick J. Wong
2019-10-25 15:03 ` [PATCH 8/8] xfs: cleanup use of the XFS_ALLOC_ flags Christoph Hellwig
2019-10-28 16:32 ` 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=20191028161245.GD15222@magnolia \
--to=darrick.wong@oracle.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.