From: Brian Foster <bfoster@redhat.com>
To: Christoph Hellwig <hch@lst.de>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH 3/8] xfs: don't use delalloc extents for COW on files with extsize hints
Date: Thu, 21 Feb 2019 12:58:17 -0500 [thread overview]
Message-ID: <20190221175817.GA51494@bfoster> (raw)
In-Reply-To: <20190218091827.12619-4-hch@lst.de>
On Mon, Feb 18, 2019 at 10:18:22AM +0100, Christoph Hellwig wrote:
> While using delalloc for extsize hints is generally a good idea, the
> current code that does so only for COW doesn't help us much and creates
> a lot of special cases. Switch it to use real allocations like we
> do for direct I/O.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> fs/xfs/xfs_iomap.c | 28 +++++++++++++++++-----------
> fs/xfs/xfs_reflink.c | 10 +++++++++-
> fs/xfs/xfs_reflink.h | 3 ++-
> 3 files changed, 28 insertions(+), 13 deletions(-)
>
> diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
> index a7599b084571..19a3331b4a56 100644
> --- a/fs/xfs/xfs_iomap.c
> +++ b/fs/xfs/xfs_iomap.c
> @@ -918,22 +918,28 @@ xfs_file_iomap_begin(
> * been done up front, so we don't need to do them here.
> */
> if (xfs_is_reflink_inode(ip)) {
> + struct xfs_bmbt_irec orig = imap;
> +
...
> + error = xfs_reflink_allocate_cow(ip, &imap, &shared, &lockmode,
> + flags);
> + if (error)
> + goto out_unlock;
> +
> + /*
> + * For buffered writes we need to report the address of the
> + * previous block (if there was any) so that the higher level
> + * write code can perform read-modify-write operations. For
> + * direct I/O code, which must be block aligned we need to
> + * report the newly allocated address.
> + */
> + if (!(flags & IOMAP_DIRECT) &&
> + orig.br_startblock != HOLESTARTBLOCK)
> + imap = orig;
I find the logic here kind of confusing. The buffered write (reflink)
path basically expects to allocated COW blocks over an existing shared
extent. It thus makes no modification to the caller's imap because it
(read-modify-)writes into cache and writeback determines where to send
the I/O. Why not follow the same flow here? For example:
cmap = orig;
error = xfs_reflink_allocate_cow(ip, &cmap, ...);
/* ... */
if ((flags & IOMAP_DIRECT) || (imap.br_startblock == HOLESTARTBLOCK))
imap = cmap;
And also, what's the point of the hole check.. to avoid an unnecessary
data fork allocation below? That should be explained in the comment.
>
> end_fsb = imap.br_startoff + imap.br_blockcount;
> length = XFS_FSB_TO_B(mp, end_fsb) - offset;
> diff --git a/fs/xfs/xfs_reflink.c b/fs/xfs/xfs_reflink.c
> index 2babc2cbe103..8a5353daf9ab 100644
> --- a/fs/xfs/xfs_reflink.c
> +++ b/fs/xfs/xfs_reflink.c
> @@ -397,7 +397,8 @@ xfs_reflink_allocate_cow(
> struct xfs_inode *ip,
> struct xfs_bmbt_irec *imap,
> bool *shared,
> - uint *lockmode)
> + uint *lockmode,
> + unsigned iomap_flags)
I don't see why a lower level reflink mechanism needs to care about
direct I/O or not. IMO this should just be a 'bool convert' param.
Brian
> {
> struct xfs_mount *mp = ip->i_mount;
> xfs_fileoff_t offset_fsb = imap->br_startoff;
> @@ -471,6 +472,13 @@ xfs_reflink_allocate_cow(
> if (nimaps == 0)
> return -ENOSPC;
> convert:
> + /*
> + * COW fork extents are supposed to remain unwritten until we're ready
> + * to initiate a disk write. For direct I/O we are going to write the
> + * data and need the conversion, but for buffered writes we're done.
> + */
> + if (!(iomap_flags & IOMAP_DIRECT))
> + return 0;
> return xfs_reflink_convert_cow_extent(ip, imap, offset_fsb, count_fsb);
>
> out_unreserve:
> diff --git a/fs/xfs/xfs_reflink.h b/fs/xfs/xfs_reflink.h
> index 6d73daef1f13..70d68a1a9b49 100644
> --- a/fs/xfs/xfs_reflink.h
> +++ b/fs/xfs/xfs_reflink.h
> @@ -15,7 +15,8 @@ extern int xfs_reflink_trim_around_shared(struct xfs_inode *ip,
> extern int xfs_reflink_reserve_cow(struct xfs_inode *ip,
> struct xfs_bmbt_irec *imap);
> extern int xfs_reflink_allocate_cow(struct xfs_inode *ip,
> - struct xfs_bmbt_irec *imap, bool *shared, uint *lockmode);
> + struct xfs_bmbt_irec *imap, bool *shared, uint *lockmode,
> + unsigned iomap_flags);
> extern int xfs_reflink_convert_cow(struct xfs_inode *ip, xfs_off_t offset,
> xfs_off_t count);
>
> --
> 2.20.1
>
next prev parent reply other threads:[~2019-02-21 17:58 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-18 9:18 COW improvements and always_cow support V5 Christoph Hellwig
2019-02-18 9:18 ` [PATCH 1/8] xfs: make xfs_bmbt_to_iomap more useful Christoph Hellwig
2019-02-18 9:18 ` [PATCH 2/8] xfs: fix SEEK_DATA for speculative COW fork preallocation Christoph Hellwig
2019-02-19 5:13 ` Darrick J. Wong
2019-02-18 9:18 ` [PATCH 3/8] xfs: don't use delalloc extents for COW on files with extsize hints Christoph Hellwig
2019-02-19 5:17 ` Darrick J. Wong
2019-02-21 17:58 ` Brian Foster [this message]
2019-02-21 22:56 ` Darrick J. Wong
2019-02-22 14:16 ` Christoph Hellwig
2019-02-18 9:18 ` [PATCH 4/8] xfs: also truncate holes covered by COW blocks Christoph Hellwig
2019-02-18 9:18 ` [PATCH 5/8] xfs: merge COW handling into xfs_file_iomap_begin_delay Christoph Hellwig
2019-02-19 18:12 ` Darrick J. Wong
2019-02-21 17:59 ` Brian Foster
2019-02-21 21:30 ` Darrick J. Wong
2019-02-22 12:31 ` Brian Foster
2019-02-22 14:22 ` Christoph Hellwig
2019-02-22 14:20 ` Christoph Hellwig
2019-02-22 15:20 ` Brian Foster
2019-02-18 9:18 ` [PATCH 6/8] xfs: make COW fork unwritten extent conversions more robust Christoph Hellwig
2019-02-19 18:16 ` Darrick J. Wong
2019-02-18 9:18 ` [PATCH 7/8] xfs: report IOMAP_F_SHARED from xfs_file_iomap_begin_delay Christoph Hellwig
2019-02-19 5:20 ` Darrick J. Wong
2019-02-18 9:18 ` [PATCH 8/8] xfs: introduce an always_cow mode Christoph Hellwig
2019-02-19 5:25 ` Darrick J. Wong
2019-02-19 17:53 ` Darrick J. Wong
2019-02-20 14:58 ` Christoph Hellwig
2019-02-20 15:00 ` Christoph Hellwig
2019-02-19 18:31 ` Darrick J. Wong
2019-02-20 15:08 ` Christoph Hellwig
2019-02-21 17:31 ` Darrick J. Wong
2019-02-18 9:19 ` xfs/420 and xfs/421: don't disturb unwritten status with md5sum Christoph Hellwig
2019-03-09 10:32 ` Eryu Guan
2019-03-09 17:34 ` 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=20190221175817.GA51494@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 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).