Re: [PATCH 0/6] xfstests: add copy/dedupe/clone to fsx/fsstress

[Dave Chinner <david@fromorbit.com>]

On Wed, Nov 28, 2018 at 10:57:26AM +0800, Eryu Guan wrote:
> On Mon, Nov 26, 2018 at 12:38:55PM -0800, Darrick J. Wong wrote:
> > On Mon, Nov 26, 2018 at 12:19:28AM +0800, Eryu Guan wrote:
> > > On Sat, Nov 24, 2018 at 08:59:21AM -0800, Darrick J. Wong wrote:
> > > > On Fri, Nov 23, 2018 at 03:33:01PM +0800, Zorro Lang wrote:
> > > > > On Mon, Nov 19, 2018 at 08:38:09AM -0800, Darrick J. Wong wrote:
> > > > > > On Mon, Nov 19, 2018 at 06:45:47PM +0800, Zorro Lang wrote:
> > > > > > > On Mon, Nov 19, 2018 at 01:22:52PM +0800, Zorro Lang wrote:
> > > > > > > > On Tue, Nov 13, 2018 at 03:39:37PM -0800, Darrick J. Wong wrote:
> > > > > > > > > Hi all,
> > > > > > > > > 
> > > > > > > > > This series adds to fsx support for FICLONERANGE, FIDEDUPERANGE, and
> > > > > > > > > copy_file_range.  It adds to fsstress support for copy_file_range.
> > > > > > > > > There are known failures in 4.20-rc2, particularly with copy_file_range,
> > > > > > > > > so these patches provide a fstests base for everyone to start/continue
> > > > > > > > > looking for bugs.
> > > > > > > > 
> > > > > > > > Hi Darrick,
> > > > > > > > 
> > > > > > > > Your patches triggered 2 new failures on g/091 and g/263, refer to [1]. I can't
> > > > > > > > reproduce these failures on original xfstests [2]. I saw you were talking about g/091
> > > > > > > > in #xfs. Are these two failures same issue?
> > > > > > 
> > > > > > Most probably.  Dave and I are still digging through all the new
> > > > > > failures that show up in g/091, g/263, and g/127 once clonerange starts
> > > > > > happening.
> > > > > 
> > > > > Hi Darrick,
> > > > > 
> > > > > I just tried NFS, [1] tested with original xfstests, [2] tested with your
> > > > > patches. Looks like your patches bring in new failures to NFS test:
> > > > > g/075, g/112 and g/127.
> > > > 
> > > > Uh... it would be much more helpful to send along the golden output
> > > > diffs that show where fsx went bad (as well as the nfs configuration),
> > > 
> > > I was testing against a loop-mount nfsv4.2 server. The diff is like
> > > 
> > > @@ -1,3 +1,46 @@
> > >  QA output created by 263
> > >  fsx -N 10000 -o 8192 -l 500000 -r PSIZE -t BSIZE -w BSIZE -Z
> > >  fsx -N 10000 -o 128000 -l 500000 -r PSIZE -t BSIZE -w BSIZE -Z
> > > +Seed set to 1
> > > +skipping zero size read
> > > +truncating to largest ever: 0xe400
> > > +copying to largest ever: 0x1f400
> > > +cloning to largest ever: 0x70000
> > > +copy range: 0x4b000 to 0x64000 at 0x2800
> > > +do_copy_range:: Resource temporarily unavailable
> > 
> > Hmm, well, -EAGAIN isn't documented as a valid return code in the
> > manpage, but I guess it wouldn't hurt to retry.  For that matter, I
> > should probably amend do_copy_file_range to use syscall() so that we
> > don't pick up the glibc wrapper by the same name.
> 
> Ah, this is not the error I usually see. A more common pattern I saw is
> do_copy_range fails with EINVAL.
> 
> skipping zero size read
> 3 mapwrite      0x8e7c thru     0x1507f (0xc204 bytes)
> 16 read 0xa5d5 thru     0x1507f (0xaaab bytes)
> 20 mapwrite     0x1a687 thru    0x2151d (0x6e97 bytes)
> 21 read 0x130b5 thru    0x16a8c (0x39d8 bytes)
> 24 read 0x1f899 thru    0x2151d (0x1c85 bytes)
> truncating to largest ever: 0x1abb7
> 25 trunc        from 0x2151e to 0x1abb7
> 26 mapread      0x1731a thru    0x1abb6 (0x389d bytes)
> 31 write        0x371bd thru    0x3dbdd (0x6a21 bytes)
> 35 write        0x3b913 thru    0x3ffff (0x46ed bytes)
> 36 write        0x283af thru    0x3341f (0xb071 bytes)
> 37 mapread      0x29ebb thru    0x35ef6 (0xc03c bytes)
> 38 write        0x25c9 thru     0x63d2  (0x3e0a bytes)
> 39 mapwrite     0x16f57 thru    0x1e75a (0x7804 bytes)
> 42 mapread      0x36992 thru    0x3aa7d (0x40ec bytes)
> 43 mapread      0x1f22b thru    0x23b9f (0x4975 bytes)
> 45 trunc        from 0x40000 to 0x1356b
> 46 write        0xaf3e thru     0x185d3 (0xd696 bytes)
> 48 write        0x1c700 thru    0x20d2c (0x462d bytes)
> truncating to largest ever: 0x1fdbf
> 52 trunc        from 0x20d2d to 0x1fdbf
> copying to largest ever: 0x27a75
> 58 copy from 0x86a9 to 0x12fe2, (0xa939 bytes) at 0x1d13c
> copy range: 0x86a9 to 0x12fe2 at 0x1d13c
> do_copy_range:: Invalid argument

fsx is always going to fail with NFSv4.2 and copy_file_range() right
now, because NFS does not allow copy offload within the same file.
i.e. it only allows copying between different files.


> copy_range on the same file fails with "Invalid argument" but copy to a
> new file succeeds. So I guess NFS doesn't like/support copy_file_range
> if src == dst.

Precisely - this is /currently/ an expected failure on NFS.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com