From: Brian Foster <bfoster@redhat.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH v3 6/6] xfs: use the latest extent at writeback delalloc conversion time
Date: Thu, 24 Jan 2019 09:01:21 -0500 [thread overview]
Message-ID: <20190124140121.GB2855@bfoster> (raw)
In-Reply-To: <20190124085230.GB24774@infradead.org>
On Thu, Jan 24, 2019 at 12:52:30AM -0800, Christoph Hellwig wrote:
> And this I really don't like. I much prefer the full version
> I've done here, which has evolved a bit from the work I've been
> posting to the list for months now:
>
This patch is just an incremental step in that direction to fix the
underlying problem. The functionality with regard to imap race
mitigation in the delalloc conversion path is essentially equivalent.
The difference is you've cleaned up the API further by lifting the
lookup into the caller and implementing a more proper conversion
implemention.
> http://git.infradead.org/users/hch/xfs.git/shortlog/refs/heads/xfs-mapping-validation.2
>
> Which also fixes up some layering issues we have in that code path.
Ok... I've not reviewed the details but as noted above, the approach to
dealing with imap validity looks sane to me. Essentially all I'm asking
for here is isolated patches for fixes vs. refactoring vs. whatever
other cleanups/changes were related to the always cow stuff and offering
this (or the v2 patch) as an already tested way to do that.
If you'd rather just put this all in your series, then please split this
all up into a patch per logical change (i.e., separate patches to
move/rename functions first, introduce the new bmapi delalloc conversion
helper, modify writeback to use said helper, the layering fixups you're
referring to, etc.). At a glance, the commit above looks like it could
easily be split into at least 3 or 4 patches.
Brian
prev parent reply other threads:[~2019-01-24 14:01 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-23 18:41 [PATCH v3 0/6] xfs: properly invalidate cached writeback mapping Brian Foster
2019-01-23 18:41 ` [PATCH v3 1/6] xfs: eof trim writeback mapping as soon as it is cached Brian Foster
2019-02-01 7:58 ` Christoph Hellwig
2019-02-01 17:40 ` Darrick J. Wong
2019-01-23 18:41 ` [PATCH v3 2/6] xfs: update fork seq counter on data fork changes Brian Foster
2019-01-23 18:41 ` [PATCH v3 3/6] xfs: validate writeback mapping using data fork seq counter Brian Foster
2019-01-23 18:41 ` [PATCH v3 4/6] xfs: remove superfluous writeback mapping eof trimming Brian Foster
2019-01-23 18:41 ` [PATCH v3 5/6] xfs: create delalloc bmapi wrapper for full extent allocation Brian Foster
2019-01-24 8:51 ` Christoph Hellwig
2019-01-24 14:03 ` Brian Foster
2019-01-23 18:41 ` [PATCH v3 6/6] xfs: use the latest extent at writeback delalloc conversion time Brian Foster
2019-01-24 8:52 ` Christoph Hellwig
2019-01-24 14:01 ` 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=20190124140121.GB2855@bfoster \
--to=bfoster@redhat.com \
--cc=hch@infradead.org \
--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).