From: Christoph Hellwig <hch@infradead.org>
To: Brian Foster <bfoster@redhat.com>
Cc: Christoph Hellwig <hch@infradead.org>, linux-xfs@vger.kernel.org
Subject: Re: [PATCH v2 5/5] xfs: revalidate imap properly before writeback delalloc conversion
Date: Wed, 23 Jan 2019 10:14:12 -0800 [thread overview]
Message-ID: <20190123181412.GA23710@infradead.org> (raw)
In-Reply-To: <20190122181327.GA23651@bfoster>
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
next prev parent reply other threads:[~2019-01-23 18:14 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 [this message]
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=20190123181412.GA23710@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.