Linux block layer
 help / color / mirror / Atom feed
From: John Meneghini <jmeneghi@redhat.com>
To: Jesse Taube <jtaubepe@redhat.com>, linux-block@vger.kernel.org
Cc: linux-nvme@lists.infradead.org, shinichiro.kawasaki@wdc.com,
	Daniel Wagner <dwagner@suse.de>
Subject: Re: [PATCH v2 0/2] Test multipath and marginal ports
Date: Wed, 19 Aug 2026 17:49:53 -0400	[thread overview]
Message-ID: <0d3cb83e-a4b6-414d-8756-fafd4a8238bc@redhat.com> (raw)
In-Reply-To: <20260819200425.194743-1-jtaubepe@redhat.com>

This is a great improvement and we now have a functioning blkstest 070 to test the FPIN LI kernel patches.

The problem is: I don't think we are done yet.  In my own private testing and development with these patches I've been working on a next-version test that combines the ANA states from test/nvme/057 with test/nvme/070. So I am working on a test 071.

The good news is: everything now works with test/nvme/070.  The bad news is: the kernel patches are not done.

What I've found is: a long as the ANA states are all optimized or non-optimized everything works.  However, once we throw in an inaccessible state to the mix, we run into serious problems.

At this point in development I don't care about the test failures in my test/nvme/071 script. I expect the script to bug out because it doesn't understand the inaccessible state. The test sill continues flipping rports in and out of the marginal state and keeps going. That's what it is designed to do. That means it is testing all of the code paths in the kernel patches.

The problem is: when turning marginal paths on and off with controllers that are in the inaccessible state, the path selection algorithm in the kernel fails and we end up with the following:

[Wed Aug 19 16:25:42 2026] nvme_ns_head_submit_bio: 6 callbacks suppressed
[Wed Aug 19 16:25:42 2026] block nvme2n1: no usable path - requeuing I/O
[Wed Aug 19 16:25:42 2026] block nvme2n1: no usable path - requeuing I/O
[Wed Aug 19 16:25:42 2026] block nvme2n1: no usable path - requeuing I/O
[Wed Aug 19 16:25:42 2026] block nvme2n1: no usable path - requeuing I/O
[Wed Aug 19 16:25:42 2026] block nvme2n1: no usable path - requeuing I/O
[Wed Aug 19 16:25:42 2026] block nvme2n1: no usable path - requeuing I/O
[Wed Aug 19 16:25:42 2026] block nvme2n1: no usable path - requeuing I/O
[Wed Aug 19 16:25:42 2026] block nvme2n1: no usable path - requeuing I/O
[Wed Aug 19 16:25:42 2026] block nvme2n1: no usable path - requeuing I/O
[Wed Aug 19 16:25:42 2026] block nvme2n1: no usable path - requeuing I/O

At this point the fio jobs are still running but there is no progress.  This means no path was found and ALL of the IOs got re-queued. And if we flip the marginal state off on all of the controllers IO continues to be hung.  The IO scheduler is hung and there is no possibility of getting it restarted again.

So this is a really serious bug in the kernel patches and we can't ship this stuff until we fix the problem.

This IO re-requeing problem should NEVER happen - no matter what the state of the marginal paths.

So I can recommend that Shinichiro test these patches with the current upstream kernel patches:

   https://lore.kernel.org/linux-nvme/20260812181300.3712426-1-jtaubepe@redhat.com/
   
But there will be another version of Kernel patches and a V3 of this patch set will be forth coming.
  
John A. Meneghini
Senior Principal Platform Storage Engineer
RHEL SST - Platform Storage Group
jmeneghi@redhat.com

On 8/19/26 16:04, Jesse Taube wrote:
> Tests for the upcoming nvme-fc: FPIN link integrity handling set.
> It tests for various multipath and marginal port
> scenarios, while confirming the port usage and state. The test is
> intended to emulate receiving an FPIN event in a multipath environment.
> 
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=220329
> Link: https://github.com/linux-blktests/blktests/pull/264
> 
> Jesse Taube (2):
>    nvme: Add _setup_nvmet_port_marginal
>    nvme/070: Test multipath and marginal ports
> 
>   common/nvme        |  31 +++
>   tests/nvme/070     | 613 +++++++++++++++++++++++++++++++++++++++++++++
>   tests/nvme/070.out |  43 ++++
>   3 files changed, 687 insertions(+)
>   create mode 100755 tests/nvme/070
>   create mode 100644 tests/nvme/070.out
> 


  parent reply	other threads:[~2026-08-19 21:50 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-19 20:04 [PATCH v2 0/2] Test multipath and marginal ports Jesse Taube
2026-08-19 20:04 ` [PATCH v2 1/2] nvme: Add _setup_nvmet_port_marginal Jesse Taube
2026-08-19 20:04 ` [PATCH v2 2/2] nvme/070: Test multipath and marginal ports Jesse Taube
2026-08-19 21:49 ` John Meneghini [this message]
2026-08-20 14:09   ` [PATCH v2 0/2] " John Meneghini
2026-08-23 12:24   ` Shin'ichiro Kawasaki

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=0d3cb83e-a4b6-414d-8756-fafd4a8238bc@redhat.com \
    --to=jmeneghi@redhat.com \
    --cc=dwagner@suse.de \
    --cc=jtaubepe@redhat.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=shinichiro.kawasaki@wdc.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox