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
