From: Nilay Shroff <nilay@linux.ibm.com>
To: Christoph Hellwig <hch@lst.de>
Cc: linux-nvme@lists.infradead.org, linux-block@vger.kernel.org,
kbusch@kernel.org, hare@suse.de, sagi@grimberg.me,
jmeneghi@redhat.com, axboe@kernel.dk, gjoyce@ibm.com
Subject: Re: [RFC PATCH 2/2] nvme-multipath: remove multipath module param
Date: Fri, 18 Apr 2025 19:52:06 +0530 [thread overview]
Message-ID: <e50e568c-9a9b-4306-a2f4-e108791e83d2@linux.ibm.com> (raw)
In-Reply-To: <20250409104515.GB5359@lst.de>
On 4/9/25 4:15 PM, Christoph Hellwig wrote:
> On Tue, Apr 08, 2025 at 08:05:20PM +0530, Nilay Shroff wrote:
>> Okay, we can add an option to avoid making this behavior "the default".
>> So do you recommend adding a module option for opting in this behavior
>> change or something else?
>
> I guess a module option as default makes sense. I'd still love to figure
> out a way to have per-controller options of some kind as e.g. this
> option make very little sense for thunderbolt-attached external devices.
>
> But unfortunately I'm a bit lost what a good interface for that would be.
>
>
I don't know how to make this option per-controller as you know the
head node, typically, refers to namespace paths and each path then
refers to different controller. So if we were to make this option
per controller then how could we handle it in case one controller has
this option set but then the another controller doesn't set this
option. It could be confusing.
How about module option "nvme_core.multipath_head_always"? The default is
set to false. So now it becomes two step process:
1. modprobe nvme_core multipath_head_always=Y && modprobe nvme
2. echo "<val>" > /sys/block/nvme0XnY/delayed_shutdown_sec
Thanks,
--Nilay
next prev parent reply other threads:[~2025-04-18 14:22 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-21 6:37 [RFC PATCH 0/2] improve NVMe multipath handling Nilay Shroff
2025-03-21 6:37 ` [RFC PATCH 1/2] nvme-multipath: introduce delayed removal of the multipath head node Nilay Shroff
2025-03-22 1:48 ` Martin K. Petersen
2025-03-22 22:08 ` Nilay Shroff
2025-03-25 15:21 ` John Meneghini
2025-04-07 14:44 ` Christoph Hellwig
2025-04-08 14:07 ` Nilay Shroff
2025-04-09 10:43 ` Christoph Hellwig
2025-04-18 10:45 ` Nilay Shroff
2025-04-22 7:36 ` Christoph Hellwig
2025-04-22 9:52 ` Nilay Shroff
2025-03-21 6:37 ` [RFC PATCH 2/2] nvme-multipath: remove multipath module param Nilay Shroff
2025-03-25 15:09 ` John Meneghini
2025-04-07 14:45 ` Christoph Hellwig
2025-04-08 14:35 ` Nilay Shroff
2025-04-09 10:45 ` Christoph Hellwig
2025-04-18 14:22 ` Nilay Shroff [this message]
2025-04-22 7:36 ` Christoph Hellwig
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=e50e568c-9a9b-4306-a2f4-e108791e83d2@linux.ibm.com \
--to=nilay@linux.ibm.com \
--cc=axboe@kernel.dk \
--cc=gjoyce@ibm.com \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=jmeneghi@redhat.com \
--cc=kbusch@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=sagi@grimberg.me \
/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