From: Omar Sandoval <osandov@osandov.com>
To: Bart Van Assche <bvanassche@acm.org>
Cc: "jthumshirn@suse.de" <jthumshirn@suse.de>,
"osandov@fb.com" <osandov@fb.com>,
"msnitzer@redhat.com" <msnitzer@redhat.com>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>
Subject: Re: [PATCH blktests 0/3] Add NVMeOF multipath tests
Date: Tue, 18 Sep 2018 17:18:15 -0700 [thread overview]
Message-ID: <20180919001815.GF479@vader> (raw)
In-Reply-To: <e73f116a-f665-7222-1c3e-63ef1c031687@acm.org>
On Tue, Sep 18, 2018 at 05:02:47PM -0700, Bart Van Assche wrote:
> On 9/18/18 4:24 PM, Omar Sandoval wrote:
> > On Tue, Sep 18, 2018 at 02:20:59PM -0700, Bart Van Assche wrote:
> > > Can you have a look at the updated master branch of
> > > https://github.com/bvanassche/blktests? That code should no longer fail if
> > > unloading the nvme kernel module fails. Please note that you will need
> > > kernel v4.18 to test these scripts - a KASAN complaint appears if I run
> > > these tests against kernel v4.19-rc4.
> >
> > Thanks, these pass now. Is it expected that my nvme device gets a
> > multipath device configured after running these tests?
> >
> > $ lsblk
> > NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
> > vda 254:0 0 16G 0 disk
> > └─vda1 254:1 0 16G 0 part /
> > vdb 254:16 0 8G 0 disk
> > vdc 254:32 0 8G 0 disk
> > vdd 254:48 0 8G 0 disk
> > nvme0n1 259:0 0 8G 0 disk
> > └─mpatha 253:0 0 8G 0 mpath
>
> No, all multipath devices that were created during a test should be removed
> before that test finishes. I will look into this.
>
> > Also, can you please fix:
> >
> > _have_kernel_option NVME_MULTIPATH && exit 1
> >
> > to not exit on failure? It should use SKIP_REASON and return 1. You
> > might need to add something like _dont_have_kernel_option to properly
> > handle the case where the config is not found.
>
> OK, I will change this.
>
> > Side note which isn't a blocker for merging is that there's a lot of
> > duplicated code between these helpers and the srp helpers. How hard
> > would it be to refactor that?
>
> Are you perhaps referring to the code that is shared between the
> tests/srp/rc tests/nvmeof-mp/rc shell scripts?
Yes, those.
> The hardest part is probably
> to chose a location where to store these functions. Should I create a file
> with common code under common/, under tests/srp/, under tests/nvmeof-mp/ or
> perhaps somewhere else?
Just put it under common.
Thanks!
next prev parent reply other threads:[~2018-09-19 5:53 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20180815203728.19521-1-bart.vanassche@wdc.com>
[not found] ` <20180815203728.19521-4-bart.vanassche@wdc.com>
2018-08-17 14:24 ` [PATCH blktests 3/3] Add NVMeOF dm-mpath tests Mike Snitzer
2018-08-17 15:46 ` Bart Van Assche
2018-08-17 16:04 ` Mike Snitzer
[not found] ` <20180820073059.quvg3bh4ngv5ka4x@linux-x5ow.site>
[not found] ` <ee851ae7b88a93b9b5c9f1b0c6e206944c0b3c64.camel@wdc.com>
[not found] ` <20180821064619.7tyhlst74qkrw4fi@linux-x5ow.site>
2018-08-23 1:53 ` [PATCH blktests 0/3] Add NVMeOF multipath tests Bart Van Assche
2018-08-24 0:21 ` Omar Sandoval
2018-09-13 1:06 ` Omar Sandoval
2018-09-16 4:28 ` Bart Van Assche
2018-09-18 21:20 ` Bart Van Assche
2018-09-18 23:24 ` Omar Sandoval
2018-09-19 0:02 ` Bart Van Assche
2018-09-19 0:18 ` Omar Sandoval [this message]
2018-09-27 23:26 ` Bart Van Assche
2018-10-05 18:50 ` Omar Sandoval
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=20180919001815.GF479@vader \
--to=osandov@osandov.com \
--cc=bvanassche@acm.org \
--cc=jthumshirn@suse.de \
--cc=linux-block@vger.kernel.org \
--cc=msnitzer@redhat.com \
--cc=osandov@fb.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.