Re: [PATCH v2 0/2] Test multipath and marginal ports
John Meneghini <[email protected]>
| Newsgroups | org.kernel.vger.linux-block,org.infradead.lists.linux-nvme |
|---|---|
| Organization | RHEL Core Storge Team |
| Message-ID | <[email protected]> |
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/[email protected]/ 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 [email protected] 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 >