linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Brian Foster <bfoster@redhat.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH v2 5/5] xfs: revalidate imap properly before writeback delalloc conversion
Date: Wed, 23 Jan 2019 13:40:34 -0500	[thread overview]
Message-ID: <20190123184034.GB27886@bfoster> (raw)
In-Reply-To: <20190123181412.GA23710@infradead.org>

On Wed, Jan 23, 2019 at 10:14:12AM -0800, Christoph Hellwig wrote:
> On Tue, Jan 22, 2019 at 01:13:28PM -0500, Brian Foster wrote:
> > > So, the nimaps == 0 case hits even for the data fork when running
> > > xfs/442 on a 1k block size file system.  That test has generally been
> > > a fun source of bugs in the always_cow series.
> > 
> > Hmm, Ok.. any idea how/why that is? I'm curious if this is an artifact
> > of this code being racy (i.e., nimaps == 0 occurs somehow on a range
> > external to the page) or there is some legitimate means to lose a
> > delalloc block under the locked page. If the latter, we should at least
> > document it in the code..
> 
> I haven't managed to pinpint it mostly because xfs_bmapi_write is
> such an unreadable mess.  Based on that I decided to implement the idea
> of a separate xfs_bmapi_delalloc_convert helper again, mostly to try
> to understand what actuall is going on.  This seems to work pretty
> reasonable after initial testing, except that it seems to unhide an
> issue in xfs/109 which doesn't look directly related.  The current
> status is here:
> 
> http://git.infradead.org/users/hch/xfs.git/shortlog/refs/heads/xfs-mapping-validation.2
> 

I have a v3 of this series that does something similar, but doesn't
quite take the refactoring as far. I just created an
xfs_bmapi_delalloc() wrapper over xfs_bmapi_write(). The changes to the
latter are minimal based on a tweak of XFS_BMAPI_DELALLOC behavior. The
change to xfs_iomap_write_allocate() is basically just to use the new
helper instead of xfs_bmapi_write().

The refactoring you have looks like the right direction to me, but I'm
wondering why we need to change so much all at once, particularly since
it's not clear that some of this -EAGAIN stuff is really necessary.
Pulling bits out of xfs_bmapi_write() is also inherently more difficult
to review than reusing it, IMO.

Hmm, I'm wondering if we could rebase your refactoring onto the simple
wrapper in my patch. You'd basically just reimplement the helper, kill
off the XFS_BMAPI_DELALLOC stuff as you already have, and the changes to
xfs_iomap_write_allocate() (notwithstanding moving/renaming the
function, which should really be split up into separate patches) would
probably be minimal (i.e., do the extent lookup).

I was still running some tests but I've got through a decent amount
already and have everything formatted to send out so I'll just post
it...

Brian

      reply	other threads:[~2019-01-23 18:40 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
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 [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=20190123184034.GB27886@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).