linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 8/9] xfs: optimize xfs_reflink_end_cow
Date: Thu, 13 Oct 2016 09:06:39 +0200	[thread overview]
Message-ID: <20161013070639.GE10579@lst.de> (raw)
In-Reply-To: <20161012141536.GD56019@bfoster.bfoster>

On Wed, Oct 12, 2016 at 10:15:37AM -0400, Brian Foster wrote:
> > +	xfs_bmap_search_extents(ip, end_fsb - 1, XFS_COW_FORK, &eof, &idx,
> > +			&got, &prev);
> > +	if (eof) {
> > +		ASSERT(idx > 0);
> > +		xfs_bmbt_get_all(xfs_iext_get_ext(ifp, --idx), &got);
> > +	}
> 
> Hmm, should this happen? Do we really want to proceed with the previous
> extent?

Yes.  This is the same pattern as xfs_bunmapi and it is needed.  For
an explanation we need to recall the semantics of xfs_bmap_search_extents,
which gives us the extent at bno IFF there is one, else if gives us the
extent beyond bno.

So we search for the last extent in the to be deleted range here,
but if there is no extent at the end of the range we'll get a return
outside the range, in which case we need to back one up (which
bunmapi does and we catch somewhat confusingly with the trim_extent
and goto next_extent, I should clean that up..), but as a special
case we can get the eof case where there is no extent beyong bno.

> I suppose the extent trim below would catch if we've dropped outside the
> range of the I/O, but note that if trim extent sets blockcount = 0, it
> doesn't necessarily reset the start offset for the (del.br_startoff ==
> offset_fsb) check at next_extent. Perhaps that should break once the del
> end offset precedes offset_fsb..?
> 
> Either way, it would be nice to have a comment here if there's some
> reason we shouldn't just bail out or flag a problem...

Yes, both this code and bumapi could use some cleanup..

> Maybe it's just me, but I find this whole loop kind of confusing. I
> realize it is tricky because we have to handle several different cases
> with regard to index (no more extents to the left, bmap_del_extent_cow()
> pushing index forward or back).

I found it rather confusing as well.
> 
> In staring at it a bit, I'm wondering if something like the following
> would work:
> 
> 	/* walk backwards until we're out of the I/O range... */
> 	while (got.br_startoff + got.br_blockcount > offset_fsb) {
> 		del = got;
> 		xfs_trim_extent(&del, offset_fsb, end_fsb - offset_fsb);
> 		/* extent delete may have bumped idx forward */
> 		if (!del.br_blockcount) {
> 			idx--;
> 			goto next_extent;
> 		}
> 
> 		...
> 
> next_extent:
> 		if (idx < 0)
> 			break;
> 		xfs_bmbt_get_all(xfs_iext_get_ext(ifp, idx), &got);
> 	}
> 
> Thoughts?

That looks reasonable, I'll see if it passes xfstests.. :)

  reply	other threads:[~2016-10-13  7:16 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
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 [this message]
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 8/9] xfs: optimize xfs_reflink_end_cow Christoph Hellwig
2016-10-17 17:53   ` Brian Foster
2016-10-17 18: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=20161013070639.GE10579@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).