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 > > > +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. Thanks, Eryu
