Re: xfstests xfs fuzzers fail with DAX

On Mon, Aug 29, 2016 at 7:37 PM, Darrick J. Wong
[off-list ref] wrote:

On Mon, Aug 29, 2016 at 06:50:05PM -0700, Dan Williams wrote:

quoted

[ Adding Darrick on the off chance that this triggers an "aha, of
course it does!" ]

Aha!  Of course it does!!! :)

Heh, thanks :).  And apologies to Dave for missing his earlier note
pointing out the delalloc failure, linux-nvdimm list ate the response.

quoted

Darrick these corruption tests you added to xfstests last year all
fail the same way with DAX enabled.  They spew:

    "pwrite64: Structure needs cleaning"

...reports that are cleaned up by running without "-o dax".

I think this happens because in non-dax mode, the pwrite is a buffered
write and so long as we can create a delalloc reservation, everything
is ok and nothing fails.  Whereas for dax we have to allocate the
blocks for the pwrite immediately, thereby triggering the cntbt
verifier error.

Proceeding from the assumption "DAX behaves a lot like DIO", all the
tests that rely on buffered mode semantics are going to choke if DAX
is turned on without them knowing about it.

quoted

Alternatively you could sit back and watch me try to figure it out,
that should be quite entertaining... as a start I'll try to pin down a
stack trace when the error is returned.

As for how to fix this, probably the best option is to change line 98
to 'pwrite -W -S 0x62...' and update the output to include the
'structure needs cleaning' message.

I'll give it a shot.

Or get rid of the mount option and require explicitly turning on DAX
on a per-inode basis, which I think is where Dave is already going.

Yes, I think we can't run away from the dax mount option fast enough.
The semantics are different, so an application / administrator needs
to explicitly opt-in to DAX semantics per-inode otherwise we are
guaranteed to cause surprises.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs