mirror of
https://github.com/linux-apfs/apfstests.git
synced 2026-05-01 15:01:44 -07:00
Anand Jain
3c48a2ca20
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>
50 lines
1.2 KiB
Plaintext
50 lines
1.2 KiB
Plaintext
QA output created by 021
|
|
1. into a hole
|
|
ef2e0d18474b2151ef5876b1e89c2f1d
|
|
2. into allocated space
|
|
0: [0..383]: extent
|
|
cc767c0ddc3ff5704c2de7f801707d85
|
|
3. into unwritten space
|
|
0: [0..383]: extent
|
|
ef2e0d18474b2151ef5876b1e89c2f1d
|
|
4. hole -> data
|
|
0: [0..127]: hole
|
|
1: [128..255]: extent
|
|
2: [256..383]: hole
|
|
05424d688bd9df682d20616d21940871
|
|
5. hole -> unwritten
|
|
0: [0..127]: hole
|
|
1: [128..255]: extent
|
|
2: [256..383]: hole
|
|
ef2e0d18474b2151ef5876b1e89c2f1d
|
|
6. data -> hole
|
|
0: [0..127]: extent
|
|
1: [128..383]: hole
|
|
da95adcbefc28ba59b21cf335c516c6f
|
|
7. data -> unwritten
|
|
0: [0..255]: extent
|
|
1: [256..383]: hole
|
|
da95adcbefc28ba59b21cf335c516c6f
|
|
8. unwritten -> hole
|
|
0: [0..127]: extent
|
|
1: [128..383]: hole
|
|
ef2e0d18474b2151ef5876b1e89c2f1d
|
|
9. unwritten -> data
|
|
0: [0..255]: extent
|
|
1: [256..383]: hole
|
|
05424d688bd9df682d20616d21940871
|
|
10. hole -> data -> hole
|
|
0dfbe8aa4c20b52e1b8bf3cb6cbdf193
|
|
11. data -> hole -> data
|
|
0: [0..255]: extent
|
|
d48858312a922db7eb86377f638dbc9f
|
|
12. unwritten -> data -> unwritten
|
|
0: [0..255]: extent
|
|
0dfbe8aa4c20b52e1b8bf3cb6cbdf193
|
|
13. data -> unwritten -> data
|
|
0: [0..255]: extent
|
|
d48858312a922db7eb86377f638dbc9f
|
|
14. data -> hole @ 0
|
|
0: [0..383]: extent
|
|
cc767c0ddc3ff5704c2de7f801707d85
|