From: Keith Busch <kbusch@kernel.org>
To: Krishna Iyer <kiyer@crusoe.ai>
Cc: hare@suse.de, axboe@kernel.dk, hch@lst.de, sagi@grimberg.me,
linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org,
nilay@linux.ibm.com, sjpark@crusoe.ai, saravanand@crusoe.ai
Subject: Re: [PATCH v3] nvme-multipath: add fail_if_no_path sysfs attribute
Date: Thu, 24 Sep 2026 09:43:56 -0600 [thread overview]
Message-ID: <arVFPIKeT-HoYF2K@kbusch-mbp> (raw)
In-Reply-To: <20260924063524.26807-1-kiyer@crusoe.ai>
On Wed, Sep 23, 2026 at 11:35:24PM -0700, Krishna Iyer wrote:
> Yes, exactly. Some namespaces should keep waiting out the reconnect
> while others should stop waiting and fail their parked I/O, decided
> by a condition only userspace can see. Here that condition is a
> killed process stuck in D state on parked I/O that nothing will ever
> consume (for us a SIGKILLed VM the host must reap), and it could be
> any consumer known to be gone. Failing that namespace lets the
> process exit, while namespaces with live users behind the same
> controllers keep queueing and carry on when paths return. A
> controller wide timeout cannot separate the two, and there is no
> duration to pick up front since the trigger is userspace observing
> the event. Reconnect itself is untouched either way. So the kernel
> provides the per namespace switch and the decision stays in
> userspace.
Okay, I see. Pehaps instead of having one controller export all the
namespaces, why not configure your target to have multiple subsystems
the client makes independent connections to for each namespace?
prev parent reply other threads:[~2026-09-24 15:43 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-23 0:49 Krishna Iyer
2026-09-23 12:06 ` Hannes Reinecke
2026-09-23 21:48 ` Keith Busch
2026-09-23 22:57 ` Krishna Iyer
2026-09-24 1:07 ` Keith Busch
2026-09-24 6:35 ` Krishna Iyer
2026-09-24 15:43 ` Keith Busch [this message]
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=arVFPIKeT-HoYF2K@kbusch-mbp \
--to=kbusch@kernel.org \
--cc=axboe@kernel.dk \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=kiyer@crusoe.ai \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=nilay@linux.ibm.com \
--cc=sagi@grimberg.me \
--cc=saravanand@crusoe.ai \
--cc=sjpark@crusoe.ai \
/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
all inboxes | Powered by JetHome®