| Message ID | 20200220200632.14075-1-jmoyer@redhat.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | fstests: fixes for 64k pages and dax | expand |
On Thu, Feb 20, 2020 at 03:06:29PM -0500, Jeff Moyer wrote: > This set of patches fixes a few false positives I encountered when > testing DAX on ppc64le (which has a 64k page size). > > Patch 1 is actually not specific to non-4k page sizes. Currently, > each individual dm rc file checks for the presence of the DAX mount > option, and _notruns the test as part of the initializtion. This > doesn't work for the snapshot target. Moving the check into the > _require_dm_target fixes the problem, and keeps from the cut-n-paste > of boilerplate. > > Patches 2 and 3 get rid of hard coded block/page sizes in the tests. > They run just fine on 64k pages and 64k block sizes. > > Even after these patches, there are many more tests that fail in the > following configuration: > > MKFS_OPTIONS="-b size=65536 -m reflink=0" MOUNT_OPTIONS="-o dax" > > One class of failures is tests that create a really small file system > size. Some of those tests seem to require the very small size, but > others seem like they could live with a slightly bigger size that > would then fit the log (the typical failure is a mkfs failure due to > not enough blocks for the log). For the former case, I'm tempted to > send patches to _notrun those tests, and for the latter, I'd like to > bump the file system sizes up. 300MB seems to be large enough to > accommodate the log. Would folks be opposed to those approaches? Seems fine to me. Do we have a helper function to compute (or maybe just format) the minimum supported filesystem size for the given MKFS_OPTIONS? > Another class of failure is tests that either hard-code a block size > to trigger a specific error case, or that test a multitude of block > sizes. I'd like to send a patch to _notrun those tests if there is > a user-specified block size. That will require parsing the MKFS_OPTIONS > based on the fs type, of course. Is that something that seems > reasonable? I think it's fine to _notrun a test that requires a specific blocksize when when that blocksize is not supported by the system under test. The ones that cycle through a range of block sizes, not so much--I guess the question here is can we distinguish "test only this blocksize" vs "default to this block size"? And do we want to? --D > I will follow up with a series of patches to implement those changes > if there is consensus on the approach. These first three seemed > straight-forward to me, so that's where I'm starting. > > Changes in v2: > - patch 2: remove the boilerplate from all dm rc files (Zorro Lang) > - cc fstests (thanks, Dave) > > [PATCH V2 1/3] dax/dm: disable testing on devices that don't support > [PATCH V2 2/3] t_mmap_collision: fix hard-coded page size > [PATCH V2 3/3] xfs/300: modify test to work on any fs block size >
Hi, Darrick, "Darrick J. Wong" <darrick.wong@oracle.com> writes: >> One class of failures is tests that create a really small file system >> size. Some of those tests seem to require the very small size, but >> others seem like they could live with a slightly bigger size that >> would then fit the log (the typical failure is a mkfs failure due to >> not enough blocks for the log). For the former case, I'm tempted to >> send patches to _notrun those tests, and for the latter, I'd like to >> bump the file system sizes up. 300MB seems to be large enough to >> accommodate the log. Would folks be opposed to those approaches? > > Seems fine to me. Do we have a helper function to compute (or maybe > just format) the minimum supported filesystem size for the given > MKFS_OPTIONS? Not that I could find. I'm not sure how you'd do that, even. >> Another class of failure is tests that either hard-code a block size >> to trigger a specific error case, or that test a multitude of block >> sizes. I'd like to send a patch to _notrun those tests if there is >> a user-specified block size. That will require parsing the MKFS_OPTIONS >> based on the fs type, of course. Is that something that seems >> reasonable? > > I think it's fine to _notrun a test that requires a specific blocksize > when when that blocksize is not supported by the system under test. OK. > The ones that cycle through a range of block sizes, not so much--I guess > the question here is can we distinguish "test only this blocksize" vs > "default to this block size"? And do we want to? Well, I'd like to prevent false test failures. In this instance, the block size is required in order for the system to function. I'm guessing this is a new and special kind of suck. If we treat the MKFS_OPTIONS as advisory, then there will be false positive failures. If we treat MKFS_OPTIONS as mandatory, then there will be less test coverage for a given set of options. I think that's the preferrable solution, but I'm probably too focused on this one use case. -Jeff