[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200114193934.GA23311@iweiny-DESK2.sc.intel.com>
Date: Tue, 14 Jan 2020 11:39:36 -0800
From: Ira Weiny <ira.weiny@...el.com>
To: "Darrick J. Wong" <darrick.wong@...cle.com>
Cc: linux-kernel@...r.kernel.org,
Alexander Viro <viro@...iv.linux.org.uk>,
Dan Williams <dan.j.williams@...el.com>,
Dave Chinner <david@...morbit.com>,
Christoph Hellwig <hch@....de>,
"Theodore Y. Ts'o" <tytso@....edu>, Jan Kara <jack@...e.cz>,
linux-ext4@...r.kernel.org, linux-xfs@...r.kernel.org,
linux-fsdevel@...r.kernel.org
Subject: Re: [RFC PATCH V2 10/12] fs/xfs: Fix truncate up
On Tue, Jan 14, 2020 at 11:00:57AM -0800, 'Ira Weiny' wrote:
> On Mon, Jan 13, 2020 at 05:14:07PM -0800, Darrick J. Wong wrote:
> > On Mon, Jan 13, 2020 at 04:40:47PM -0800, Ira Weiny wrote:
> > > On Mon, Jan 13, 2020 at 02:27:55PM -0800, Darrick J. Wong wrote:
> > > > On Fri, Jan 10, 2020 at 11:29:40AM -0800, ira.weiny@...el.com wrote:
> > > > > From: Ira Weiny <ira.weiny@...el.com>
[snip]
>
> >
> > > But as I said in the cover I am not 100% sure of
> > > this fix.
> >
> > > From what I can tell xfs_ioctl_setattr_dax_invalidate() should invalidate the
> > > mappings and the page cache and the traces I have indicate that the DAX mode
> > > is not changing or was properly held off.
> >
> > Hmm, that implies the invalidation didn't work. Can you find a way to
> > report the contents of the page cache after the dax mode change
> > invalidation fails? I wonder if this is something dorky like rounding
> > down such that the EOF page doesn't actually get invalidated?
> >
> > Hmm, no, xfs_ioctl_setattr_dax_invalidate should be nuking all the
> > pages... do you have a quick reproducer?
>
> I thought I did...
>
> What I have done is take this patch:
>
> https://www.spinics.net/lists/fstests/msg13313.html
>
> and put [run_fsx ""] in a loop... (diff below) And without this truncate fix
> patch it was failing in about 5 - 10 iterations. But I'm running it right now
> and it has gone for 30+... :-(
Ok... perhaps this is a qemu problem? In qemu I had a slightly different
script; 'test-suite.sh' (attached). This was copied to create the xfstest I
sent. Without this 'fix truncate patch I get something like the following
after in just a few iterations.
...
*** run 'fsx ' racing with setting/clearing the DAX flag
*** run 'fsx ' racing with setting/clearing the DAX flag
FAILED: fsx exited with status : 205
see trace_output
zero_range to largest ever: 0x19867
truncating to largest ever: 0x3fb6d
zero_range to largest ever: 0x40000
Mapped Write: non-zero data past EOF (0x3ab88) page offset 0xb89 is 0xe71c
LOG DUMP (15817 total operations):
15818(202 mod 256): SKIPPED (no operation)
15819(203 mod 256): ZERO 0x2ae9f thru 0x3346c (0x85ce bytes)
15820(204 mod 256): READ 0x3637 thru 0x91e6 (0x5bb0 bytes)
15821(205 mod 256): MAPREAD 0x38a80 thru 0x3d014 (0x4595 bytes)
15822(206 mod 256): INSERT 0x28000 thru 0x29fff (0x2000 bytes)
Ira
>
> I am 90% confident that this series works for 100% of the use cases we have. I
> think this is an existing bug which I've just managed to find. And again I'm
> not comfortable with this patch either. So I'm not trying to argue for it but
> I just don't know what could be wrong...
>
> Ira
>
> diff --git a/tests/generic/999 b/tests/generic/999
> index 6dd5529dbc65..929c20c6db04 100755
> --- a/tests/generic/999
> +++ b/tests/generic/999
> @@ -274,7 +274,9 @@ function run_fsx {
> pid=""
> }
>
> -run_fsx ""
> +while [ 1 ]; do
> + run_fsx ""
> +done
> run_fsx "-A"
> run_fsx "-Z -r 4096 -w 4096"
>
View attachment "test-suite.sh" of type "text/plain" (7345 bytes)
Powered by blists - more mailing lists