xfstests xfs fuzzers fail with DAX

[Dave Chinner]

On Wed, Aug 03, 2016 at 10:00:09PM -0500, Eric Sandeen wrote:
> On 8/3/16 9:45 PM, Xiong Zhou wrote:
> > Hi,
> > 
> > A few xfs fuzzers in xfstests fail with dax mount option, pass without dax.
> > They are xfs/086 xfs/088 xfs/089 xfs/091.
> > 
> > xfstests to commit 4470ad4c7e  (Jul 26)
> > kernel   to commit dd95069545  (Jul 24)
> > 
> > + ./check xfs/091
> > FSTYP         -- xfs (non-debug)
> > PLATFORM      -- Linux/x86_64 rhel73 4.7.0+
> > MKFS_OPTIONS  -- -f -bsize=4096 /dev/pmem1
> > MOUNT_OPTIONS -- -o context=system_u:object_r:nfs_t:s0 /dev/pmem1 /daxsch
> > 
> > xfs/091	 104s
> > Ran: xfs/091
> > Passed all 1 tests
> > 
> > + echo 'MOUNT_OPTIONS="-o dax"'
> > + ./check xfs/091
> > FSTYP         -- xfs (non-debug)
> > PLATFORM      -- Linux/x86_64 rhel73 4.7.0+
> > MKFS_OPTIONS  -- -f -bsize=4096 /dev/pmem1
> > MOUNT_OPTIONS -- -o dax -o context=system_u:object_r:nfs_t:s0 /dev/pmem1 /daxsch
> > 
> > xfs/091 104s ...  - output mismatch (see /root/xfstests/results//xfs/091.out.bad)
> >     --- tests/xfs/091.out	2016-07-18 02:57:47.670000000 -0400
> >     +++ /root/xfstests/results//xfs/091.out.bad	2016-08-03 22:38:14.948000000 -0400
> >     @@ -6,6 +6,70 @@
> >      + corrupt image
> >      + mount image
> >      + modify files
> >     +pwrite64: Structure needs cleaning
> >     +pwrite64: Structure needs cleaning
> >     +pwrite64: Structure needs cleaning
> >     +pwrite64: Structure needs cleaning
> 
> This means the filesystem has shut down, most likely, and more information about
> the error is in dmesg.
>
> Further, if the filesystem is corrupt, xfs_repair output would be interesting.
> 
> Can you provide that information?
> 
> This can probably be reproduced, but when reporting a bug it's always good to provide
> as many details as you can.

What it indicates to me is that DAX detects inode/freespace  metadata
related corruption sooner than non-DAX paths because we don't do
delayed allocation on DAX. i.e. we are doing direct allocation in
the syscall path and errors that would have been detected in the
writeback path and triggered until sync/unmount are now triggering
in the pwrite() syscall path.

Hence I think this is probably expected behaviour, and not a bug or
regression. We probably should just filter the pwrite errors out...

Cheers,

Dave.
-- 
Dave Chinner
david at fromorbit.com