All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Foster <bfoster@redhat.com>
To: linux-xfs@vger.kernel.org
Subject: [PATCH v3 0/6] xfs: properly invalidate cached writeback mapping
Date: Wed, 23 Jan 2019 13:41:25 -0500	[thread overview]
Message-ID: <20190123184131.46188-1-bfoster@redhat.com> (raw)

Hi all,

Here's v3 of the imap cache invalidation series. To recap from v2, patch
5 of that series added a lookup and extent trim to
xfs_iomap_write_allocate() to ensure delalloc conversion always had a
correct range. Christoph didn't like this approach and has an alternate
proposal to modify XFS_BMAPI_DELALLOC behavior to always skip holes.
That approach is problematic because it can potentially convert blocks
that have nothing to do with the current extent (i.e., still racy with
hole punch).

As a compromise, this version implements an xfs_bmapi_delalloc() wrapper
with an interface that allocates the underlying extent of a particular
block. This ensures that writeback always uses the correct range without
adding an extra extent lookup. There is still a bit of hackiness and
probably opportunity for broader refactoring, but that can be done once
we've established correctness.

Patches 1-4 are mostly unchanged from v2. Patch 5 introduces the
xfs_bmapi_delalloc() helper. Patch 6 modifies xfs_iomap_write_allocate()
to use xfs_bmapi_delalloc() instead of xfs_bmapi_write(). This series
survives fstests (including repeated cycles of generic/524 and xfs/442)
on 4k and 1k block sizes with reflink enabled without any regressions.
It also survives several million fsx operations.

Thoughts, reviews, flames appreciated.

Brian

v3:
- Move comment in xfs_imap_valid().
- Replace lookup+trim in xfs_iomap_write_allocate() with
  xfs_bmapi_delalloc() wrapper mechanism.
v2: https://marc.info/?l=linux-xfs&m=154775280823464&w=2
- Refactor validation logic into xfs_imap_valid() helper.
- Revalidate seqno after the lock cycle in xfs_map_blocks().
- Update *seq in xfs_iomap_write_allocate() regardless of fork type.
- Add patch 5 for seqno revalidation on xfs_iomap_write_allocate() lock
  cycles.
v1: https://marc.info/?l=linux-xfs&m=154721212321112&w=2

Brian Foster (6):
  xfs: eof trim writeback mapping as soon as it is cached
  xfs: update fork seq counter on data fork changes
  xfs: validate writeback mapping using data fork seq counter
  xfs: remove superfluous writeback mapping eof trimming
  xfs: create delalloc bmapi wrapper for full extent allocation
  xfs: use the latest extent at writeback delalloc conversion time

 fs/xfs/libxfs/xfs_bmap.c       |  58 ++++++++---
 fs/xfs/libxfs/xfs_bmap.h       |   3 +-
 fs/xfs/libxfs/xfs_iext_tree.c  |  13 ++-
 fs/xfs/libxfs/xfs_inode_fork.h |   2 +-
 fs/xfs/xfs_aops.c              |  71 ++++++++-----
 fs/xfs/xfs_iomap.c             | 175 ++++++++++++---------------------
 6 files changed, 162 insertions(+), 160 deletions(-)

-- 
2.17.2

             reply	other threads:[~2019-01-23 18:41 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-23 18:41 Brian Foster [this message]
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

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=20190123184131.46188-1-bfoster@redhat.com \
    --to=bfoster@redhat.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 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.