[Top] [All Lists]

Re: fsx failure on 3.10.0-rc1+ (xfstests 263) -- Mapped Read: non-zero d

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: fsx failure on 3.10.0-rc1+ (xfstests 263) -- Mapped Read: non-zero data past EOF
From: Brian Foster <bfoster@xxxxxxxxxx>
Date: Mon, 10 Jun 2013 19:17:22 -0400
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20130610213100.GC29376@dastard>
References: <51B5D1EB.9080200@xxxxxxxxxx> <20130610213100.GC29376@dastard>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6
On 06/10/2013 05:31 PM, Dave Chinner wrote:
> On Mon, Jun 10, 2013 at 09:17:31AM -0400, Brian Foster wrote:
>> Hi guys,
>> I wanted to get this onto the list... I suspect this could be
>> similar/related to the issue reported here:
>> http://oss.sgi.com/archives/xfs/2013-06/msg00066.html
> Unlikely - generic/263 tests mmap IO vs direct IO, and Sage's
> problem has neither...

Oh, Ok. I didn't look at that one closely enough then.

>> While running xfstests, the only apparent regression I hit from 3.9.0
>> was generic/263. This test fails due to the following command (and
>> resulting output):
> Not a regression - 263 has been failing ever since it was introduced
> in 2011 by:
> commit 0d69e10ed15b01397e8c6fd7833fa3c2970ec024
> It is testing mmap() writes vs direct IO, something that is known to
> be fundamentally broken (i.e. racy) as mmap() page fault path does
> not hold the XFS_IOLOCK or i_mutex in any way.  The direct IO path
> tries to wark around this by flushing and invalidating cached pages
> before IO submission, but the lack of locking in the page fault path
> means we can't avoid the race entirely.

Thanks for the explanation.

>> P.S., I also came across the following thread which, if related,
>> suggests this might be known/understood to a degree:
>> http://oss.sgi.com/archives/xfs/2012-04/msg00703.html
> Yup, that's potentially one aspect of it. However, have you run the
> test code on ext3/4? it works just fine - it's only XFS that has
> problems with this case, so it's not clear that this is a DIO
> problem. It was never able to work out where ext3/ext4 were zeroing
> the part of the page beyond EOF, and I couldn't ever make the DIO
> code reliably do the right thing. It's one of the reasons that lead
> to this discussion as LSFMM:
> http://lwn.net/Articles/548351/

Interesting, thanks again. I did happen to run the script and the fsx
test on the ext4 rootfs of my VM and observed expected behavior.

Note that I mentioned this was harder to reproduce with fixed alloc
sizes less than 128k or so. I don't believe ext4 does any kind of
speculative preallocation in the manner that XFS does. Perhaps that is a


> Cheers,
> Dave.

<Prev in Thread] Current Thread [Next in Thread>