All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Brian Foster <bfoster@redhat.com>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH v2 5/5] xfs: revalidate imap properly before writeback delalloc conversion
Date: Fri, 18 Jan 2019 08:31:32 -0800	[thread overview]
Message-ID: <20190118163132.GA6318@infradead.org> (raw)
In-Reply-To: <20190118115937.GD7807@infradead.org>

On Fri, Jan 18, 2019 at 03:59:37AM -0800, Christoph Hellwig wrote:
> xfs_bmapi_write will always do a xfs_iext_lookup_extent for the
> passed in blocks anyway.  So this trimming logic should move into
> xfs_bmapi_write to ensure it does the right thing, instead of papering
> over the logic in xfs_bmapi_write in the caller with another lookup.
> 
> I think the improved XFS_BMAPI_DELALLOC handling in this patch:
> 
>    http://git.infradead.org/users/hch/xfs.git/commitdiff/553fed9ce7695df081779c6a9a205af4142b2a06
> 
> is the right answer, as writeback really should only ever convert
> existing delalloc extents, and I'd much rather rely on that rather than
> piling hacks of hacks to feed the right range into a function that must
> do a lookup in the extent tree anyway.

FYI, here is a tree that rebases my patches on top of your (minus this
one) and also drops the internal i_size checks, although it still keeps
the initial one for the truncate fast path.  Testing is still ongoing,
and for the writeback issue you probably only need the first three
of my patches:

	http://git.infradead.org/users/hch/xfs.git/shortlog/refs/heads/xfs-mapping-validation

  reply	other threads:[~2019-01-18 16:31 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-17 19:19 [PATCH v2 0/5] xfs: properly invalidate cached writeback mapping Brian Foster
2019-01-17 19:20 ` [PATCH v2 1/5] xfs: eof trim writeback mapping as soon as it is cached Brian Foster
2019-01-18  5:29   ` Allison Henderson
2019-01-18 11:47   ` Christoph Hellwig
2019-01-17 19:20 ` [PATCH v2 2/5] xfs: update fork seq counter on data fork changes Brian Foster
2019-01-18  5:30   ` Allison Henderson
2019-01-17 19:20 ` [PATCH v2 3/5] xfs: validate writeback mapping using data fork seq counter Brian Foster
2019-01-18  6:12   ` Allison Henderson
2019-01-18 11:50   ` Christoph Hellwig
2019-01-17 19:20 ` [PATCH v2 4/5] xfs: remove superfluous writeback mapping eof trimming Brian Foster
2019-01-18  6:48   ` Allison Henderson
2019-01-18 11:25     ` Brian Foster
2019-01-18 11:50   ` Christoph Hellwig
2019-01-17 19:20 ` [PATCH v2 5/5] xfs: revalidate imap properly before writeback delalloc conversion Brian Foster
2019-01-18  6:58   ` Allison Henderson
2019-01-18 11:59   ` Christoph Hellwig
2019-01-18 16:31     ` Christoph Hellwig [this message]
2019-01-18 18:39       ` Brian Foster
2019-01-20 12:45         ` Brian Foster
2019-01-21 15:51           ` Christoph Hellwig
2019-01-21 17:43             ` Brian Foster
2019-01-21 15:48         ` Christoph Hellwig
2019-01-21 17:42           ` Brian Foster
2019-01-22 17:14             ` Christoph Hellwig
2019-01-22 18:13               ` Brian Foster
2019-01-23 18:14                 ` Christoph Hellwig
2019-01-23 18:40                   ` 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=20190118163132.GA6318@infradead.org \
    --to=hch@infradead.org \
    --cc=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.