From: Ross Zwisler <ross.zwisler@linux.intel.com>
To: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Xiong Zhou <xzhou@redhat.com>,
fstests@vger.kernel.org, dan.j.williams@intel.com
Subject: Re: [PATCH] DAX DIO: DAX mapped area DIO to non-DAX expected failure
Date: Tue, 14 Mar 2017 09:07:02 -0600 [thread overview]
Message-ID: <20170314150702.GA1036@linux.intel.com> (raw)
In-Reply-To: <20170314144403.GA25951@linux.intel.com>
On Tue, Mar 14, 2017 at 08:44:03AM -0600, Ross Zwisler wrote:
> On Tue, Mar 14, 2017 at 11:59:20AM +0800, Xiong Zhou wrote:
> > It's not supported on raw mode nvdimm, brd ramdisk:
> > https://lists.01.org/pipermail/linux-nvdimm/2017-February/008959.html
> >
> > It's working on "memory mode" nvdimm, memmap ramdisk.
> >
> > Mute output of this subtest to stop the fake failure. Keep this
> > routine for sanity check.
> >
> > Updating generic/413 and xfs/260.
>
> I don't understand how we can mute the errors that are due to DAX direct I/O
> being used in unsupported configurations (raw mode nvdimm, brd ramdisk)
> without also muting real errors that happen for supported configs (memory mode
> nvidmm)?
>
> It seems like for this test to give us proper coverage, we need to see this
> output in all cases, and we just need to document to the user that this test
> is expected to fail if you run it against brd or raw mode nvdimms?
Actually the best thing to do would probably be to teach xfstests which are
the unsupported configs for DIO + DAX, and then just skip the tests so we
don't report false positive failures. I think we can do this by looking at
the device (pmem vs brd), and by looking at the output from ndctl to see what
mode the pmem namespace is in. If they have a pmem namespace but no ndctl,
just assume the test is runnable and run the risk of getting a false positive.
next prev parent reply other threads:[~2017-03-14 15:07 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-14 3:59 [PATCH] DAX DIO: DAX mapped area DIO to non-DAX expected failure Xiong Zhou
2017-03-14 14:44 ` Ross Zwisler
2017-03-14 15:07 ` Ross Zwisler [this message]
2017-03-15 2:28 ` Xiong Zhou
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=20170314150702.GA1036@linux.intel.com \
--to=ross.zwisler@linux.intel.com \
--cc=dan.j.williams@intel.com \
--cc=fstests@vger.kernel.org \
--cc=xzhou@redhat.com \
/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.