linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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 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 \
    --subject='Re: [PATCH] iomap: set page dirty after partial delalloc on mkwrite' \
    /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

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).