* Re: [PATCH 0/3] fstests: fixes for 64k pages and dax
[not found] <20200205224818.18707-1-jmoyer@redhat.com>
@ 2020-02-05 23:06 ` Dave Chinner
2020-02-06 14:36 ` Jeff Moyer
[not found] ` <20200205224818.18707-2-jmoyer@redhat.com>
1 sibling, 1 reply; 4+ messages in thread
From: Dave Chinner @ 2020-02-05 23:06 UTC (permalink / raw)
To: Jeff Moyer; +Cc: linux-fsdevel, linux-xfs, fstests
[cc fstests@vger.kernel.org]
On Wed, Feb 05, 2020 at 05:48:15PM -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. Right now we
> only test for dax incompatibility in the dm flakey target. This means
> that tests that use dm-thin or the snapshot target will still try to
> run. Moving the check to _require_dm_target fixes that problem.
>
> 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?
>
> 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 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.
>
> Thanks!
> Jeff
>
> [PATCH 1/3] dax/dm: disable testing on devices that don't support dax
> [PATCH 2/3] t_mmap_collision: fix hard-coded page size
> [PATCH 3/3] xfs/300: modify test to work on any fs block size
Hi Jeff,
You probably should be sending fstests patches to
fstests@vger.kernel.org, otherwise they probably won't get noticed
by the fstests maintainer...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH 1/3] dax/dm: disable testing on devices that don't support dax
[not found] ` <20200205224818.18707-2-jmoyer@redhat.com>
@ 2020-02-06 5:08 ` Zorro Lang
2020-02-06 14:35 ` Jeff Moyer
0 siblings, 1 reply; 4+ messages in thread
From: Zorro Lang @ 2020-02-06 5:08 UTC (permalink / raw)
To: Jeff Moyer; +Cc: linux-xfs, fstests
On Wed, Feb 05, 2020 at 05:48:16PM -0500, Jeff Moyer wrote:
> Move the hack out of dmflakey and put it into _require_dm_target. This
> fixes up a lot of missed tests that are failing due to the lack of dax
> support (such as tests on dm-thin, snapshot, etc).
>
> Signed-off-by: Jeff Moyer <jmoyer@redhat.com>
> ---
> common/dmflakey | 5 -----
> common/rc | 11 +++++++++++
> 2 files changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/common/dmflakey b/common/dmflakey
> index 2af3924d..b4e11ae9 100644
> --- a/common/dmflakey
> +++ b/common/dmflakey
> @@ -8,11 +8,6 @@ FLAKEY_ALLOW_WRITES=0
> FLAKEY_DROP_WRITES=1
> FLAKEY_ERROR_WRITES=2
>
> -echo $MOUNT_OPTIONS | grep -q dax
> -if [ $? -eq 0 ]; then
> - _notrun "Cannot run tests with DAX on dmflakey devices"
> -fi
If we need to remove this for common/dmflakey, why not do the same thing
in common/dmthin and common/dmdelay etc ?
> -
> _init_flakey()
> {
> local BLK_DEV_SIZE=`blockdev --getsz $SCRATCH_DEV`
> diff --git a/common/rc b/common/rc
> index eeac1355..785f34c6 100644
> --- a/common/rc
> +++ b/common/rc
> @@ -1874,6 +1874,17 @@ _require_dm_target()
> _require_sane_bdev_flush $SCRATCH_DEV
> _require_command "$DMSETUP_PROG" dmsetup
>
> + echo $MOUNT_OPTIONS | grep -q dax
> + if [ $? -eq 0 ]; then
> + case $target in
> + stripe|linear|error)
> + ;;
> + *)
> + _notrun "Cannot run tests with DAX on $target devices."
> + ;;
> + esac
> + fi
> +
> modprobe dm-$target >/dev/null 2>&1
>
> $DMSETUP_PROG targets 2>&1 | grep -q ^$target
> --
> 2.19.1
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH 1/3] dax/dm: disable testing on devices that don't support dax
2020-02-06 5:08 ` [PATCH 1/3] dax/dm: disable testing on devices that don't support dax Zorro Lang
@ 2020-02-06 14:35 ` Jeff Moyer
0 siblings, 0 replies; 4+ messages in thread
From: Jeff Moyer @ 2020-02-06 14:35 UTC (permalink / raw)
To: zlang, linux-xfs; +Cc: fstests
Zorro Lang <zlang@redhat.com> writes:
> On Wed, Feb 05, 2020 at 05:48:16PM -0500, Jeff Moyer wrote:
>> Move the hack out of dmflakey and put it into _require_dm_target. This
>> fixes up a lot of missed tests that are failing due to the lack of dax
>> support (such as tests on dm-thin, snapshot, etc).
>>
>> Signed-off-by: Jeff Moyer <jmoyer@redhat.com>
>> ---
>> common/dmflakey | 5 -----
>> common/rc | 11 +++++++++++
>> 2 files changed, 11 insertions(+), 5 deletions(-)
>>
>> diff --git a/common/dmflakey b/common/dmflakey
>> index 2af3924d..b4e11ae9 100644
>> --- a/common/dmflakey
>> +++ b/common/dmflakey
>> @@ -8,11 +8,6 @@ FLAKEY_ALLOW_WRITES=0
>> FLAKEY_DROP_WRITES=1
>> FLAKEY_ERROR_WRITES=2
>>
>> -echo $MOUNT_OPTIONS | grep -q dax
>> -if [ $? -eq 0 ]; then
>> - _notrun "Cannot run tests with DAX on dmflakey devices"
>> -fi
>
> If we need to remove this for common/dmflakey, why not do the same thing
> in common/dmthin and common/dmdelay etc ?
I didn't realize they had this same code. I'll make that change,
thanks!
-Jeff
>
>> -
>> _init_flakey()
>> {
>> local BLK_DEV_SIZE=`blockdev --getsz $SCRATCH_DEV`
>> diff --git a/common/rc b/common/rc
>> index eeac1355..785f34c6 100644
>> --- a/common/rc
>> +++ b/common/rc
>> @@ -1874,6 +1874,17 @@ _require_dm_target()
>> _require_sane_bdev_flush $SCRATCH_DEV
>> _require_command "$DMSETUP_PROG" dmsetup
>>
>> + echo $MOUNT_OPTIONS | grep -q dax
>> + if [ $? -eq 0 ]; then
>> + case $target in
>> + stripe|linear|error)
>> + ;;
>> + *)
>> + _notrun "Cannot run tests with DAX on $target devices."
>> + ;;
>> + esac
>> + fi
>> +
>> modprobe dm-$target >/dev/null 2>&1
>>
>> $DMSETUP_PROG targets 2>&1 | grep -q ^$target
>> --
>> 2.19.1
>>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH 0/3] fstests: fixes for 64k pages and dax
2020-02-05 23:06 ` [PATCH 0/3] fstests: fixes for 64k pages and dax Dave Chinner
@ 2020-02-06 14:36 ` Jeff Moyer
0 siblings, 0 replies; 4+ messages in thread
From: Jeff Moyer @ 2020-02-06 14:36 UTC (permalink / raw)
To: Dave Chinner; +Cc: linux-fsdevel, linux-xfs, fstests
Dave Chinner <david@fromorbit.com> writes:
> [cc fstests@vger.kernel.org]
>
> On Wed, Feb 05, 2020 at 05:48:15PM -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. Right now we
>> only test for dax incompatibility in the dm flakey target. This means
>> that tests that use dm-thin or the snapshot target will still try to
>> run. Moving the check to _require_dm_target fixes that problem.
>>
>> 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?
>>
>> 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 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.
>>
>> Thanks!
>> Jeff
>>
>> [PATCH 1/3] dax/dm: disable testing on devices that don't support dax
>> [PATCH 2/3] t_mmap_collision: fix hard-coded page size
>> [PATCH 3/3] xfs/300: modify test to work on any fs block size
>
> Hi Jeff,
>
> You probably should be sending fstests patches to
> fstests@vger.kernel.org, otherwise they probably won't get noticed
> by the fstests maintainer...
Hm, somehow I didn't know about that list. I'll send v2 there, thanks!
-Jeff
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-02-06 14:36 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20200205224818.18707-1-jmoyer@redhat.com>
2020-02-05 23:06 ` [PATCH 0/3] fstests: fixes for 64k pages and dax Dave Chinner
2020-02-06 14:36 ` Jeff Moyer
[not found] ` <20200205224818.18707-2-jmoyer@redhat.com>
2020-02-06 5:08 ` [PATCH 1/3] dax/dm: disable testing on devices that don't support dax Zorro Lang
2020-02-06 14:35 ` Jeff Moyer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).