All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Jeff Moyer <jmoyer@redhat.com>
Cc: fstests@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-xfs@vger.kernel.org
Subject: Re: [PATCH V2 0/3] fstests: fixes for 64k pages and dax
Date: Thu, 20 Feb 2020 13:21:00 -0800	[thread overview]
Message-ID: <20200220212100.GC9506@magnolia> (raw)
In-Reply-To: <20200220200632.14075-1-jmoyer@redhat.com>

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
> 

  parent reply	other threads:[~2020-02-20 21:21 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-20 20:06 [PATCH V2 0/3] fstests: fixes for 64k pages and dax Jeff Moyer
2020-02-20 20:06 ` [PATCH V2 1/3] dax/dm: disable testing on devices that don't support dax Jeff Moyer
2020-02-21  9:48   ` Zorro Lang
2020-02-23 15:07     ` Eryu Guan
2020-02-24  6:15       ` Zorro Lang
2020-02-20 20:06 ` [PATCH V2 2/3] t_mmap_collision: fix hard-coded page size Jeff Moyer
2020-02-21 13:53   ` Zorro Lang
2020-02-20 20:06 ` [PATCH V2 3/3] xfs/300: modify test to work on any fs block size Jeff Moyer
2020-02-22  5:31   ` Zorro Lang
2020-02-24 13:46     ` Jeff Moyer
2020-02-26  7:42       ` Zorro Lang
2020-02-20 21:21 ` Darrick J. Wong [this message]
2020-02-21 20:11   ` [PATCH V2 0/3] fstests: fixes for 64k pages and dax Jeff Moyer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200220212100.GC9506@magnolia \
    --to=darrick.wong@oracle.com \
    --cc=fstests@vger.kernel.org \
    --cc=jmoyer@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.