From: Brian Foster <bfoster@redhat.com>
To: Christoph Hellwig <hch@lst.de>
Cc: linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] iomap: set page dirty after partial delalloc on mkwrite
Date: Mon, 1 Oct 2018 06:54:48 -0400 [thread overview]
Message-ID: <20181001105448.GA53694@bfoster> (raw)
In-Reply-To: <20180930224435.GA18893@lst.de>
On Mon, Oct 01, 2018 at 12:44:35AM +0200, Christoph Hellwig wrote:
> On Fri, Sep 28, 2018 at 01:39:56PM -0400, Brian Foster wrote:
> > This problem is reliably reproduced by generic/083 on XFS on ppc64
> > systems (64k page size, 4k block size). It results in leaked
> > delalloc blocks on inode reclaim, which triggers an assert failure
> > in xfs_fs_destroy_inode() and filesystem accounting inconsistency.
>
> Interesting - I've not seen this on 1k block size / 4k page size
> systems.
>
I hadn't either. I tried again on x86-64 with a smaller block size when
I realized generic/083 only reproduced on ppc64 with 4k blocks and still
couldn't reproduce.
That said, an explicit test of the circumstances described in the commit
log (write fault on a page that performs partial delalloc and fails with
-ENOSPC) reproduces the problem reliably regardless of page size. I
suspect the 1k/512b block vs 4k page size is just too small of a window
for a sub-page/partial delalloc -ENOSPC as opposed to 4k fsb and 64k
pages to reproduce reliably via fsstress.
> > This patch addresses the problem with generic/083, but I'm still in the
> > process of running broader testing. I wanted to get it on the list for
> > review in the meantime...
>
> But in general this looks sensible to me. So if the testing passes
> this looks good to me.
As a follow up to Dave's additional testing (thanks!), I ran a few
xfstests runs on x86-64 and ppc64 over the weekend and didn't reproduce
any regressions (though I note that XFS has a high failure rate with
-bsize=64k, but that's a separate problem).
Brian
next prev parent reply other threads:[~2018-10-01 17:32 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-28 17:39 [PATCH] iomap: set page dirty after partial delalloc on mkwrite Brian Foster
2018-09-30 22:44 ` Christoph Hellwig
2018-10-01 10:54 ` Brian Foster [this message]
2018-10-01 0:31 ` Dave Chinner
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=20181001105448.GA53694@bfoster \
--to=bfoster@redhat.com \
--cc=hch@lst.de \
--cc=linux-fsdevel@vger.kernel.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).