fstests: fix _test_generic_punch() to fit 64k extent

14 test cases use _test_generic_punch(), and they work well as long
as the ext4/xfs blocksize or btrfs sectorsize is below 4K.

In the system with 64K pagesize, as the blocksize can be upto 64K or the
sectorsize can be 64K so 13/14 test cases fail, because the
test-file-size (20k) and thus the extent boundary offsets aren't
big enough to fit the larger than 4k extent size.

Commit 2f194e4e82 (generic/009: don't run
for btrfs if PAGE_SIZE > 4096) tried to address this by calling the
not_run in generic/009.

And in the function _test_generic_punch() we use multiple=4 to address
the similar problem but its limited to the subcommand fcollapse.

Now to run these test cases successfully on systems with pagesize 64k,
this patch propose to increase the default multiple=1 to multiple=16.
With this we increase the test file size from 20k to 320k and thus it
encapsulates maximum extent size of 64k here. And we can drop the
multiple=4 which is just being done similar for the cases of fcollapse
subcommand only. And it appears to me there is no harm in increasing
the file size and offsets in general for all commands instead of just
fcollapse command.

This change is tested on ext4, xfs and btrfs on system with pagesize
4K and 64K.

With this patch, these 14 test cases runs fine on system with 64K
pagesize as well as pagesize 4K. However we may hit the same
limitation at some point when we want to validate the FSs with
pagesizes -gt 64K. And this patch does not address that part as of
now.

Signed-off-by: Anand Jain <anand.jain@oracle.com>
Tested-by: Chandan Rajendra <chandan@linux.vnet.ibm.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

tests/xfs/242.out

@@ -1,77 +1,77 @@
 QA output created by 242
 	1. into a hole
-0: [0..7]: hole
-1: [8..23]: unwritten
-2: [24..39]: hole
-daa100df6e6711906b61c9ab5aa16032
+0: [0..127]: hole
+1: [128..383]: unwritten
+2: [384..639]: hole
+1aca77e2188f52a62674fe8a873bdaba
 	2. into allocated space
-0: [0..7]: data
-1: [8..23]: unwritten
-2: [24..39]: data
-cc58a7417c2d7763adc45b6fcd3fa024
+0: [0..127]: data
+1: [128..383]: unwritten
+2: [384..639]: data
+2f7a72b9ca9923b610514a11a45a80c9
 	3. into unwritten space
-0: [0..39]: unwritten
-daa100df6e6711906b61c9ab5aa16032
+0: [0..639]: unwritten
+1aca77e2188f52a62674fe8a873bdaba
 	4. hole -> data
-0: [0..7]: hole
-1: [8..23]: unwritten
-2: [24..31]: data
-3: [32..39]: hole
-cc63069677939f69a6e8f68cae6a6dac
+0: [0..127]: hole
+1: [128..383]: unwritten
+2: [384..511]: data
+3: [512..639]: hole
+286aad7ca07b2256f0f2bb8e608ff63d
 	5. hole -> unwritten
-0: [0..7]: hole
-1: [8..31]: unwritten
-2: [32..39]: hole
-daa100df6e6711906b61c9ab5aa16032
+0: [0..127]: hole
+1: [128..511]: unwritten
+2: [512..639]: hole
+1aca77e2188f52a62674fe8a873bdaba
 	6. data -> hole
-0: [0..7]: data
-1: [8..23]: unwritten
-2: [24..39]: hole
-1b3779878366498b28c702ef88c4a773
+0: [0..127]: data
+1: [128..383]: unwritten
+2: [384..639]: hole
+3976e5cc0b8a47c4cdc9e0211635f568
 	7. data -> unwritten
-0: [0..7]: data
-1: [8..31]: unwritten
-2: [32..39]: hole
-1b3779878366498b28c702ef88c4a773
+0: [0..127]: data
+1: [128..511]: unwritten
+2: [512..639]: hole
+3976e5cc0b8a47c4cdc9e0211635f568
 	8. unwritten -> hole
-0: [0..23]: unwritten
-1: [24..39]: hole
-daa100df6e6711906b61c9ab5aa16032
+0: [0..383]: unwritten
+1: [384..639]: hole
+1aca77e2188f52a62674fe8a873bdaba
 	9. unwritten -> data
-0: [0..23]: unwritten
-1: [24..31]: data
-2: [32..39]: hole
-cc63069677939f69a6e8f68cae6a6dac
+0: [0..383]: unwritten
+1: [384..511]: data
+2: [512..639]: hole
+286aad7ca07b2256f0f2bb8e608ff63d
 	10. hole -> data -> hole
-0: [0..7]: hole
-1: [8..31]: unwritten
-2: [32..39]: hole
-daa100df6e6711906b61c9ab5aa16032
+0: [0..127]: hole
+1: [128..511]: unwritten
+2: [512..639]: hole
+1aca77e2188f52a62674fe8a873bdaba
 	11. data -> hole -> data
-0: [0..7]: data
-1: [8..31]: unwritten
-2: [32..39]: data
-f6aeca13ec49e5b266cd1c913cd726e3
+0: [0..127]: data
+1: [128..511]: unwritten
+2: [512..639]: data
+0bcfc7652751f8fe46381240ccadd9d7
 	12. unwritten -> data -> unwritten
-0: [0..39]: unwritten
-daa100df6e6711906b61c9ab5aa16032
+0: [0..639]: unwritten
+1aca77e2188f52a62674fe8a873bdaba
 	13. data -> unwritten -> data
-0: [0..7]: data
-1: [8..31]: unwritten
-2: [32..39]: data
-f6aeca13ec49e5b266cd1c913cd726e3
+0: [0..127]: data
+1: [128..511]: unwritten
+2: [512..639]: data
+0bcfc7652751f8fe46381240ccadd9d7
 	14. data -> hole @ EOF
-0: [0..23]: data
-1: [24..39]: unwritten
-e1f024eedd27ea6b1c3e9b841c850404
+0: [0..383]: data
+1: [384..639]: unwritten
+eb591f549edabba2b21f80ce4deed8a9
 	15. data -> hole @ 0
-0: [0..15]: unwritten
-1: [16..39]: data
-eecb7aa303d121835de05028751d301c
+0: [0..255]: unwritten
+1: [256..639]: data
+b0c249edb75ce5b52136864d879cde83
 	16. data -> cache cold ->hole
-0: [0..15]: unwritten
-1: [16..39]: data
-eecb7aa303d121835de05028751d301c
+0: [0..255]: unwritten
+1: [256..639]: data
+b0c249edb75ce5b52136864d879cde83
 	17. data -> hole in single block file
 0: [0..7]: data
 0000000 cdcd cdcd cdcd cdcd cdcd cdcd cdcd cdcd