All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Moyer <jmoyer@redhat.com>
To: fstests@vger.kernel.org
Cc: linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org
Subject: [PATCH V2 0/3] fstests: fixes for 64k pages and dax
Date: Thu, 20 Feb 2020 15:06:29 -0500	[thread overview]
Message-ID: <20200220200632.14075-1-jmoyer@redhat.com> (raw)

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?

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.

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


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

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-20 20:06 Jeff Moyer [this message]
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 ` [PATCH V2 0/3] fstests: fixes for 64k pages and dax Darrick J. Wong
2020-02-21 20:11   ` 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=20200220200632.14075-1-jmoyer@redhat.com \
    --to=jmoyer@redhat.com \
    --cc=fstests@vger.kernel.org \
    --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.