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

["Darrick J. Wong" <darrick.wong@oracle.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.

Aha, yes... it's right there in nfs4_copy_file_range.  Uggh.

> 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
> 
> > 
> > > +LOG DUMP (32 total operations):
> > > +1(  1 mod 256): SKIPPED (no operation)
> > > +2(  2 mod 256): SKIPPED (no operation)
> > > +3(  3 mod 256): SKIPPED (no operation)
> > > +4(  4 mod 256): TRUNCATE UP    from 0x0 to 0xe400
> > > +5(  5 mod 256): INSERT 0x6000 thru 0x17fff     (0x12000 bytes)
> > > +6(  6 mod 256): ZERO     0x91be thru 0x1edf5   (0x15c38 bytes)
> > > +7(  7 mod 256): WRITE    0x3ac00 thru 0x3cdff  (0x2200 bytes) HOLE
> > > +8(  8 mod 256): MAPREAD  0x36000 thru 0x3be19  (0x5e1a bytes)
> > > +9(  9 mod 256): MAPWRITE 0x73200 thru 0x7928c  (0x608d bytes)
> > > +10( 10 mod 256): MAPREAD  0x3d000 thru 0x3f9c2 (0x29c3 bytes)
> > > +11( 11 mod 256): COLLAPSE 0x2b000 thru 0x44fff (0x1a000 bytes)
> > > +12( 12 mod 256): PUNCH    0x495fa thru 0x5f28c (0x15c93 bytes)
> > > +13( 13 mod 256): FALLOC   0x2f42a thru 0x4a8f4 (0x1b4ca bytes) INTERIOR
> > > +14( 14 mod 256): ZERO     0x530b7 thru 0x5f28c (0xc1d6 bytes)
> > > +15( 15 mod 256): MAPWRITE 0x55e00 thru 0x70d6e (0x1af6f bytes)
> > > +16( 16 mod 256): READ     0x2e000 thru 0x38fff (0xb000 bytes)
> > > +17( 17 mod 256): COLLAPSE 0x3f000 thru 0x4efff (0x10000 bytes)
> > > +18( 18 mod 256): COPY 0x28000 thru 0x42fff     (0x1b000 bytes) to 0x4400 thru 0x1f3ff
> > > +19( 19 mod 256): COLLAPSE 0x2c000 thru 0x44fff (0x19000 bytes)
> > > +20( 20 mod 256): WRITE    0x54a00 thru 0x709ff (0x1c000 bytes) HOLE
> > > +21( 21 mod 256): READ     0x53000 thru 0x69fff (0x17000 bytes)
> > > +22( 22 mod 256): MAPWRITE 0x1f200 thru 0x394bb (0x1a2bc bytes)
> > > +23( 23 mod 256): MAPREAD  0x43000 thru 0x5a2d8 (0x172d9 bytes)
> > > +24( 24 mod 256): MAPWRITE 0x23000 thru 0x38812 (0x15813 bytes)
> > > +25( 25 mod 256): WRITE    0x47800 thru 0x587ff (0x11000 bytes)
> > > +26( 26 mod 256): CLONE 0x3000 thru 0x11fff     (0xf000 bytes) to 0x61000 thru 0x6ffff
> > > +27( 27 mod 256): READ     0x6c000 thru 0x6efff (0x3000 bytes)
> > > +28( 28 mod 256): DEDUPE 0x12000 thru 0x1dfff   (0xc000 bytes) to 0x4000 thru 0xffff
> > > +29( 29 mod 256): INSERT 0x31000 thru 0x32fff   (0x2000 bytes)
> > > +30( 30 mod 256): FALLOC   0x2deac thru 0x49915 (0x1ba69 bytes) INTERIOR
> > > +31( 31 mod 256): DEDUPE 0x6f000 thru 0x71fff   (0x3000 bytes) to 0x25000 thru 0x27fff
> > > +32( 32 mod 256): COPY 0x4b000 thru 0x63fff     (0x19000 bytes) to 0x2800 thru 0x1b7ff
> > > +Log of operations saved to "/mnt/test/junk.fsxops"; replay with --replay-ops
> > > +Correct content saved for comparison
> > > +(maybe hexdump "/mnt/test/junk" vs "/mnt/test/junk.fsxgood")
> > > 
> > > And it seems like that NFSv4 doesn't like clone_file_range if src and
> > > dst point to the same file.
> > 
> > How did you conclude that nfs4 doesn't it like clone_file_range if src
> > == dest?  Operation 26 in the fsxlog shows that it did such a clone and
> > succeeded.
> 
> I typed the wrong operation name.. it should be "copy_file_range" not
> "clone_file_range".
> 
> And if I do a manual test on NFSv4.2, I got
> 
> # xfs_io -fc "copy_range -s 0 -d 0 -l 5 /mnt/test/fsx/112.0" /mnt/test/fsx/112.0
> copy_range: Invalid argument
> 
> # xfs_io -fc "copy_range -s 0 -d 0 -l 0 /mnt/test/fsx/112.0" /mnt/test/fsx/112.1
> 
> 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.

<nod> Ok, I'll rework the test_copy_range function to try a 1-byte copy.
Thanks for the info.

--D

> Thanks,
> Eryu