From: Christoph Hellwig <hch@lst.de>
To: Brian Foster <bfoster@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>,
linux-xfs@vger.kernel.org, darrick.wong@oracle.com
Subject: Re: [PATCH 5/9] xfs: optimize writes to reflink files
Date: Thu, 13 Oct 2016 08:49:25 +0200 [thread overview]
Message-ID: <20161013064925.GB10579@lst.de> (raw)
In-Reply-To: <20161012141232.GA56019@bfoster.bfoster>
On Wed, Oct 12, 2016 at 10:12:34AM -0400, Brian Foster wrote:
> > + if (xfs_is_reflink_inode(ip)) {
> > + bool shared;
> > +
> > + end_fsb = min(XFS_B_TO_FSB(mp, offset + count),
> > + maxbytes_fsb);
> > + xfs_trim_extent(&got, offset_fsb, end_fsb - offset_fsb);
> > + error = xfs_reflink_reserve_cow(ip, &got, &shared);
> > + if (error)
> > + goto out_unlock;
>
> All in all this seems fine, but I don't see why we need to get all the
> way down through xfs_reflink_reserve_cow() ->
> xfs_reflink_trim_around_shared() to handle the basic delalloc overwrite
> case on a reflink inode. Could we enhance the is_reflink_inode() helper
> or create a new one that can consider whether the data fork extent is a
> hole or delalloc?
Do you mean delalloc non-overwrite? We could skip non-overwrite extents
by factoring out a helper that checks for extent types that don't need to
be overwritten. But this would defeat the COW fork speculative
preallocation logic, which causes additional COW operations even for
extents we would not nessecarily have to COW. So we'll always have to
look at the COW fork first if we already have an allocation to implement
that scheme (and we should probably document it better).
xfs_reflink_trim_around_shared does a check for the non-COWable extent
types as the very first thing, so that's where we are done with the COW
overhead for a non-overwrite that doesn't have a speculative
preallocation in the COW fork.
next prev parent reply other threads:[~2016-10-13 7:11 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-10 13:37 optimize the COW I/O path Christoph Hellwig
2016-10-10 13:37 ` [PATCH 1/9] iomap: add IOMAP_REPORT Christoph Hellwig
2016-10-11 1:45 ` Darrick J. Wong
2016-10-11 4:58 ` Christoph Hellwig
[not found] ` <20161011144557.GA16368@lst.de>
2016-10-11 16:22 ` Darrick J. Wong
2016-10-10 13:37 ` [PATCH 2/9] xfs: add xfs_trim_extent Christoph Hellwig
2016-10-10 13:37 ` [PATCH 3/9] xfs: handle "raw" delayed extents xfs_reflink_trim_around_shared Christoph Hellwig
2016-10-10 13:38 ` [PATCH 4/9] xfs: don't bother looking at the refcount tree for reads Christoph Hellwig
2016-10-10 13:38 ` [PATCH 5/9] xfs: optimize writes to reflink files Christoph Hellwig
2016-10-12 14:12 ` Brian Foster
2016-10-13 6:49 ` Christoph Hellwig [this message]
2016-10-13 13:26 ` Brian Foster
2016-10-13 18:28 ` Darrick J. Wong
2016-10-10 13:38 ` [PATCH 6/9] xfs: refactor xfs_bunmapi_cow Christoph Hellwig
2016-10-12 14:13 ` Brian Foster
2016-10-13 6:54 ` Christoph Hellwig
2016-10-13 13:26 ` Brian Foster
2016-10-10 13:38 ` [PATCH 7/9] xfs: optimize xfs_reflink_cancel_cow_blocks Christoph Hellwig
2016-10-12 14:13 ` Brian Foster
2016-10-13 7:01 ` Christoph Hellwig
2016-10-10 13:38 ` [PATCH 8/9] xfs: optimize xfs_reflink_end_cow Christoph Hellwig
2016-10-12 14:15 ` Brian Foster
2016-10-13 7:06 ` Christoph Hellwig
2016-10-13 13:27 ` Brian Foster
2016-10-10 13:38 ` [PATCH 9/9] xfs: remove xfs_bunmapi_cow Christoph Hellwig
-- strict thread matches above, loose matches on Subject: below --
2016-10-15 8:52 optimize the COW I/O path V2 Christoph Hellwig
2016-10-15 8:52 ` [PATCH 5/9] xfs: optimize writes to reflink files Christoph Hellwig
2016-10-17 17:19 ` Brian Foster
2016-10-17 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=20161013064925.GB10579@lst.de \
--to=hch@lst.de \
--cc=bfoster@redhat.com \
--cc=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).