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: Tue, 22 Jan 2019 09:14:45 -0800 [thread overview]
Message-ID: <20190122171445.GA6717@infradead.org> (raw)
In-Reply-To: <20190121174256.GB14281@bfoster>
On Mon, Jan 21, 2019 at 12:42:56PM -0500, Brian Foster wrote:
> > It protects against the case where we migrate a COW fork mapping to the
> > data fork, which is not protected by the page lock. But I guess the
> > check warrants a comment and an assert.
> >
>
> Yeah, probably. It's not really clear to me what that means.
>
> > > 2. If so, then it also seems that the whole "eof:" thing in
> > > xfs_map_blocks() should never happen for data forks. If that's the case,
> > > the use of the eof label there seems gratuitous.
> >
> > Let me try with asserts enabled.
> >
>
> Ok, thanks.
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.
next prev parent reply other threads:[~2019-01-22 17: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 [this message]
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=20190122171445.GA6717@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.