Message ID | 20180919120053.7339-1-chandan@linux.vnet.ibm.com (mailing list archive) |
---|---|
Headers | show |
Series | Fix tests to work on non-4k block sized fs instances | expand |
On Wed, Sep 19, 2018 at 05:30:33PM +0530, Chandan Rajendra wrote: > This patchset fixes tests (mostly XFS specific ones) to work on > variable block size. These patches now use the output of "od" utility > to verify the contents of the test files instead of the md5sum > utility. > > Also, The patchset modifies _filter_fiemap() filter function to > optionally print the file offset range in block size units. > > Changelog: > V3->V4: > 1. The following tests now use _get_file_block_size() function to obtain the > underlying filesystem's block size. > xfs/009 > xfs/074 > xfs/139 > xfs/140 > xfs/299 > generic/018 > generic/177 > generic/130 > 2. xfs/139 now creates a scratch filesystem with AG size of 8192 filesystem > blocks instead of the previously used 4400 filesystem blocks. > 3. xfs/050 has now been fixed to work with 512 byte sized filesystem blocks. > The "block soft" limit and "block hard" limit values have been increased to > enable the user to have enough blocks in quota to be able to create the > required test files when using 512 byte filesystem blocks. Hi, Test passed on 512b XFS this time [1]. BTW: - xfs 64k blocksize test PASS - xfs default blocksize test PASS - ext4 64k blocksize test PASS - ext4 default blocksize test PASS So at least those cases which you modified look good to me. Thanks, Zorro [1] # ./check generic/018 generic/102 generic/108 generic/172 generic/177 generic/230 generic/235 generic/459 xfs/009 xfs/050 xfs/074 xfs/127 xfs/139 xfs/140 xfs/190 xfs/299 xfs/325 FSTYP -- xfs (debug) PLATFORM -- Linux/ppc64le ibm-p9z-16-lp5 4.18.0-xfs-debug MKFS_OPTIONS -- -f -m crc=0 -b size=512 /dev/sda5 MOUNT_OPTIONS -- -o context=system_u:object_r:root_t:s0 /dev/sda5 /mnt/xfstests/mnt2 generic/018 7s ... 6s generic/102 25s ... 24s generic/108 8s ... 8s generic/172 11s ... [not run] Reflink not supported by scratch filesystem type: xfs generic/177 4s ... 3s generic/230 18s ... 15s generic/235 3s ... 4s generic/459 41s ... 23s xfs/009 6s ... 3s xfs/050 18s ... 19s xfs/074 26s ... 26s xfs/127 14s ... [not run] Reflink not supported by scratch filesystem type: xfs xfs/139 243s ... [not run] Reflink not supported by scratch filesystem type: xfs xfs/140 286s ... [not run] Reflink not supported by scratch filesystem type: xfs xfs/190 6s ... 3s xfs/299 19s ... 13s xfs/325 4s ... [not run] Reflink not supported by scratch filesystem type: xfs Ran: generic/018 generic/102 generic/108 generic/172 generic/177 generic/230 generic/235 generic/459 xfs/009 xfs/050 xfs/074 xfs/127 xfs/139 xfs/140 xfs/190 xfs/299 xfs/325 Not run: generic/172 xfs/127 xfs/139 xfs/140 xfs/325 Passed all 17 tests > 4. The patch for xfs/299 has now been split into two. The first one fixes a bug > in the test when using 4k block size and the second one lets the user execute > the test on 64k block sized filesystems. > > Thanks to Darrick J Wong and Zorro Lang for their review comments. > > V2->V3: > Added fixes for getting generic/018, generic/108 and generic/459 tests > to work in 64k block size scenario. > > V1->V2: > Eryu Guan pointed out that some of the tests were obtaining the > filesystem's block size value from $TEST_DIR even though the test was > executed on the $SCRATCH_DEV's filesystem. This version of the > patchset fixes the following tests to obtain the block size from > $SCRATCH_MNT. The relevant changes was made to the following tests: > xfs/009, xfs/050, xfs/074, xfs/139, xfs/140, xfs/190, xfs/299, > generic/177 and generic/230. > > Chandan Rajendra (20): > Fix xfs/009 to work with 64k block size > xfs/050: Fix "Push past soft inode limit" case > Fix xfs/050 to work with 64k block size > Fix xfs/074 to work with 64k block size > Fix xfs/127 to work with 64k block size > Fix xfs/139 to work with 64k block size > Fix xfs/140 to work with 64k block size > Fix xfs/190 to work with 64k block size > xfs/299: Fix "Push past soft inode limit" case > Fix xfs/299 to work with 64k block size > xfs/325: Inject free_extent error after CoW operation > Fix generic/102 to work with 64k block size > Fix generic/172 to work with 64k block size > Filter fiemap output by FS block size > Fix generic/177 to work with 64k block size > Fix generic/230 to work with 64k block size > Fix generic/235 to work with 64k block size > Fix generic/459 to work with 64k block size > Fix generic/018 to work with 64k block size > Fix generic/108 to work with 64k block size > > common/punch | 19 ++++++++--- > tests/generic/018 | 2 +- > tests/generic/102 | 4 +-- > tests/generic/102.out | 20 +++++------ > tests/generic/108 | 4 +-- > tests/generic/172 | 4 +-- > tests/generic/177 | 20 ++++++----- > tests/generic/177.out | 23 ++++++++----- > tests/generic/230 | 23 +++++++------ > tests/generic/230.out | 16 ++++----- > tests/generic/235 | 2 +- > tests/generic/235.out | 4 +-- > tests/generic/459 | 14 ++++---- > tests/xfs/009 | 92 ++++++++++++++++++++++++++++++++++++++++++--------- > tests/xfs/009.out | 66 ++++++++++++++++++------------------ > tests/xfs/050 | 26 ++++++++++----- > tests/xfs/050.out | 60 ++++++++++++++++----------------- > tests/xfs/074 | 23 ++++++++++--- > tests/xfs/127 | 2 +- > tests/xfs/139 | 15 +++++---- > tests/xfs/139.out | 8 +++-- > tests/xfs/140 | 12 ++++--- > tests/xfs/190 | 26 ++++++++++----- > tests/xfs/299 | 29 ++++++++++------ > tests/xfs/299.out | 60 ++++++++++++++++----------------- > tests/xfs/325 | 5 +-- > tests/xfs/325.out | 2 +- > 27 files changed, 358 insertions(+), 223 deletions(-) > > -- > 2.9.5 >
On Thu, Sep 20, 2018 at 05:33:58PM +0800, Zorro Lang wrote: > On Wed, Sep 19, 2018 at 05:30:33PM +0530, Chandan Rajendra wrote: > > This patchset fixes tests (mostly XFS specific ones) to work on > > variable block size. These patches now use the output of "od" utility > > to verify the contents of the test files instead of the md5sum > > utility. > > > > Also, The patchset modifies _filter_fiemap() filter function to > > optionally print the file offset range in block size units. > > > > Changelog: > > V3->V4: > > 1. The following tests now use _get_file_block_size() function to obtain the > > underlying filesystem's block size. > > xfs/009 > > xfs/074 > > xfs/139 > > xfs/140 > > xfs/299 > > generic/018 > > generic/177 > > generic/130 > > 2. xfs/139 now creates a scratch filesystem with AG size of 8192 filesystem > > blocks instead of the previously used 4400 filesystem blocks. > > 3. xfs/050 has now been fixed to work with 512 byte sized filesystem blocks. > > The "block soft" limit and "block hard" limit values have been increased to > > enable the user to have enough blocks in quota to be able to create the > > required test files when using 512 byte filesystem blocks. > > Hi, > > Test passed on 512b XFS this time [1]. BTW: > - xfs 64k blocksize test PASS > - xfs default blocksize test PASS > - ext4 64k blocksize test PASS > - ext4 default blocksize test PASS Thanks a lot for testing, Zorro!! As I don't have access to hardware that supports 64k page, so I only tested them on x86_64 hardware. I tested all explicitly modified cases and all cases use _filter_fiemap helper, with test matrix 4k/2k/1k/512 x v4/v5/reflink/rmapbt on xfs, 4k/2k/1k on ext4 and btrfs. I also hit some other failures that we need to look into. xfs/299 fails (and only fails) on 1k block size xfs with reflink or rmapbt feature enabled. e.g. *** push past the hard inode limit (expect EDQUOT) [ROOT] 0 0 0 00 [--------] 3 0 0 00 [--------] 0 0 0 00 [--------] -[NAME] 35 25 125 00 [7 days] 9 4 10 00 [7 days] 0 0 0 00 [--------] +[NAME] 35 25 125 00 [7 days] 6 4 10 00 [7 days] 0 0 0 00 [--------] *** push past the hard block limit (expect EDQUOT) [ROOT] 0 0 0 00 [--------] 3 0 0 00 [--------] 0 0 0 00 [--------] -[NAME] =OK= 25 125 0 [7 days] 9 4 10 00 [7 days] 0 0 0 00 [--------] +[NAME] =OK= 25 125 0 [7 days] 6 4 10 00 [7 days] 0 0 0 00 [--------] ... And generic/473 fails on xfs with all test combinations. e.g. the diff on 4k block size v4 xfs 1: [256..287]: hole Hole + Data 0: [0..127]: hole -1: [128..255]: data +1: [128..135]: data Hole + Data + Hole 0: [0..127]: hole Thanks, Eryu
On Saturday, September 22, 2018 9:54:02 PM IST Eryu Guan wrote: > On Thu, Sep 20, 2018 at 05:33:58PM +0800, Zorro Lang wrote: > > On Wed, Sep 19, 2018 at 05:30:33PM +0530, Chandan Rajendra wrote: > > > This patchset fixes tests (mostly XFS specific ones) to work on > > > variable block size. These patches now use the output of "od" utility > > > to verify the contents of the test files instead of the md5sum > > > utility. > > > > > > Also, The patchset modifies _filter_fiemap() filter function to > > > optionally print the file offset range in block size units. > > > > > > Changelog: > > > V3->V4: > > > 1. The following tests now use _get_file_block_size() function to obtain the > > > underlying filesystem's block size. > > > xfs/009 > > > xfs/074 > > > xfs/139 > > > xfs/140 > > > xfs/299 > > > generic/018 > > > generic/177 > > > generic/130 > > > 2. xfs/139 now creates a scratch filesystem with AG size of 8192 filesystem > > > blocks instead of the previously used 4400 filesystem blocks. > > > 3. xfs/050 has now been fixed to work with 512 byte sized filesystem blocks. > > > The "block soft" limit and "block hard" limit values have been increased to > > > enable the user to have enough blocks in quota to be able to create the > > > required test files when using 512 byte filesystem blocks. > > > > Hi, > > > > Test passed on 512b XFS this time [1]. BTW: > > - xfs 64k blocksize test PASS > > - xfs default blocksize test PASS > > - ext4 64k blocksize test PASS > > - ext4 default blocksize test PASS > > Thanks a lot for testing, Zorro!! > > As I don't have access to hardware that supports 64k page, so I only > tested them on x86_64 hardware. I tested all explicitly modified cases > and all cases use _filter_fiemap helper, with test matrix 4k/2k/1k/512 x > v4/v5/reflink/rmapbt on xfs, 4k/2k/1k on ext4 and btrfs. I also hit some > other failures that we need to look into. Eryu, Thanks for testing the patchset. > > xfs/299 fails (and only fails) on 1k block size xfs with reflink or > rmapbt feature enabled. e.g. > > *** push past the hard inode limit (expect EDQUOT) > [ROOT] 0 0 0 00 [--------] 3 0 0 00 [--------] 0 0 0 00 [--------] > -[NAME] 35 25 125 00 [7 days] 9 4 10 00 [7 days] 0 0 0 00 [--------] > +[NAME] 35 25 125 00 [7 days] 6 4 10 00 [7 days] 0 0 0 00 [--------] > > *** push past the hard block limit (expect EDQUOT) > [ROOT] 0 0 0 00 [--------] 3 0 0 00 [--------] 0 0 0 00 [--------] > -[NAME] =OK= 25 125 0 [7 days] 9 4 10 00 [7 days] 0 0 0 00 [--------] > +[NAME] =OK= 25 125 0 [7 days] 6 4 10 00 [7 days] 0 0 0 00 [--------] > ... > I will check this and get back soon. > And generic/473 fails on xfs with all test combinations. e.g. the diff on 4k > block size v4 xfs > > 1: [256..287]: hole > Hole + Data > 0: [0..127]: hole > -1: [128..255]: data > +1: [128..135]: data > Hole + Data + Hole > 0: [0..127]: hole The above test fails even without my patches applied. This is because xfs_bmapi_read() invoked by xfs_file_iomap_begin() returns a trimmed extent. However, generic/473 passes on Ext4 with 4k blocksize.
On Mon, Sep 24, 2018 at 03:34:27PM +0530, Chandan Rajendra wrote: > On Saturday, September 22, 2018 9:54:02 PM IST Eryu Guan wrote: > > On Thu, Sep 20, 2018 at 05:33:58PM +0800, Zorro Lang wrote: > > > On Wed, Sep 19, 2018 at 05:30:33PM +0530, Chandan Rajendra wrote: > > > > This patchset fixes tests (mostly XFS specific ones) to work on > > > > variable block size. These patches now use the output of "od" utility > > > > to verify the contents of the test files instead of the md5sum > > > > utility. > > > > > > > > Also, The patchset modifies _filter_fiemap() filter function to > > > > optionally print the file offset range in block size units. > > > > > > > > Changelog: > > > > V3->V4: > > > > 1. The following tests now use _get_file_block_size() function to obtain the > > > > underlying filesystem's block size. > > > > xfs/009 > > > > xfs/074 > > > > xfs/139 > > > > xfs/140 > > > > xfs/299 > > > > generic/018 > > > > generic/177 > > > > generic/130 > > > > 2. xfs/139 now creates a scratch filesystem with AG size of 8192 filesystem > > > > blocks instead of the previously used 4400 filesystem blocks. > > > > 3. xfs/050 has now been fixed to work with 512 byte sized filesystem blocks. > > > > The "block soft" limit and "block hard" limit values have been increased to > > > > enable the user to have enough blocks in quota to be able to create the > > > > required test files when using 512 byte filesystem blocks. > > > > > > Hi, > > > > > > Test passed on 512b XFS this time [1]. BTW: > > > - xfs 64k blocksize test PASS > > > - xfs default blocksize test PASS > > > - ext4 64k blocksize test PASS > > > - ext4 default blocksize test PASS > > > > Thanks a lot for testing, Zorro!! > > > > As I don't have access to hardware that supports 64k page, so I only > > tested them on x86_64 hardware. I tested all explicitly modified cases > > and all cases use _filter_fiemap helper, with test matrix 4k/2k/1k/512 x > > v4/v5/reflink/rmapbt on xfs, 4k/2k/1k on ext4 and btrfs. I also hit some > > other failures that we need to look into. > > Eryu, Thanks for testing the patchset. > > > > > xfs/299 fails (and only fails) on 1k block size xfs with reflink or > > rmapbt feature enabled. e.g. > > > > *** push past the hard inode limit (expect EDQUOT) > > [ROOT] 0 0 0 00 [--------] 3 0 0 00 [--------] 0 0 0 00 [--------] > > -[NAME] 35 25 125 00 [7 days] 9 4 10 00 [7 days] 0 0 0 00 [--------] > > +[NAME] 35 25 125 00 [7 days] 6 4 10 00 [7 days] 0 0 0 00 [--------] > > > > *** push past the hard block limit (expect EDQUOT) > > [ROOT] 0 0 0 00 [--------] 3 0 0 00 [--------] 0 0 0 00 [--------] > > -[NAME] =OK= 25 125 0 [7 days] 9 4 10 00 [7 days] 0 0 0 00 [--------] > > +[NAME] =OK= 25 125 0 [7 days] 6 4 10 00 [7 days] 0 0 0 00 [--------] > > ... > > > > I will check this and get back soon. > > > And generic/473 fails on xfs with all test combinations. e.g. the diff on 4k > > block size v4 xfs > > > > 1: [256..287]: hole > > Hole + Data > > 0: [0..127]: hole > > -1: [128..255]: data > > +1: [128..135]: data > > Hole + Data + Hole > > 0: [0..127]: hole > > The above test fails even without my patches applied. This is because > xfs_bmapi_read() invoked by xfs_file_iomap_begin() returns a trimmed > extent. Ah, I missed that, just recalled that generic/473 is a broken test. Thanks, Eryu > > However, generic/473 passes on Ext4 with 4k blocksize. > > -- > chandan >