From: Christoph Hellwig <hch@lst.de>
To: Sagi Grimberg <sagi@grimberg.me>
Cc: Jirong Feng <jirong.feng@easystack.cn>,
Christoph Hellwig <hch@lst.de>, Keith Busch <kbusch@kernel.org>,
Jens Axboe <axboe@fb.com>,
linux-nvme@lists.infradead.org, peng.xiao@easystack.cn
Subject: Re: Should NVME_SC_INVALID_NS be translated to BLK_STS_IOERR instead of BLK_STS_NOTSUPP so that multipath(both native and dm) can failover on the failure?
Date: Wed, 31 Jan 2024 07:25:26 +0100 [thread overview]
Message-ID: <20240131062526.GA16177@lst.de> (raw)
In-Reply-To: <b3821176-b6f6-4617-92c9-ce8ad9f1118e@grimberg.me>
On Tue, Jan 30, 2024 at 01:29:33PM +0200, Sagi Grimberg wrote:
> As mentioned, afair (Hannes can correct me if I'm wrong) you can
> make an nvmet subsystem span more than 1 server assuming that the
> backend device is consistent (i.e. using drbd). The only thing that
> you need to pay attention is that the cntlid range is not overlapping
> in each of the servers that expose the nvmet subsystem (cntlid_min/max
> configfs attributes).
You can even make a subsystem span multiple "servers" without shared
storage, but in that case you'd better now allow simultaneous access to
any given namespace through path pointing to the different "servers".
ANA comes in pretty handy for that.
next prev parent reply other threads:[~2024-01-31 6:25 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-04 7:58 Should NVME_SC_INVALID_NS be translated to BLK_STS_IOERR instead of BLK_STS_NOTSUPP so that multipath(both native and dm) can failover on the failure? Jirong Feng
2023-12-04 8:47 ` Sagi Grimberg
2023-12-05 3:54 ` Jirong Feng
2023-12-05 4:37 ` Keith Busch
2023-12-05 4:40 ` Christoph Hellwig
2023-12-05 5:18 ` Keith Busch
2023-12-05 7:06 ` Jirong Feng
2023-12-05 8:50 ` Sagi Grimberg
2023-12-25 11:25 ` Jirong Feng
2023-12-25 11:40 ` Sagi Grimberg
2023-12-25 12:14 ` Jirong Feng
2023-12-26 13:27 ` Jirong Feng
2024-01-01 9:51 ` Sagi Grimberg
2024-01-02 10:33 ` Jirong Feng
2024-01-02 12:46 ` Sagi Grimberg
2024-01-03 10:24 ` Jirong Feng
2024-01-04 11:56 ` Sagi Grimberg
2024-01-30 9:36 ` Jirong Feng
2024-01-30 11:29 ` Sagi Grimberg
2024-01-31 6:25 ` Christoph Hellwig [this message]
2024-03-20 3:17 ` Jirong Feng
2024-03-20 8:51 ` Sagi Grimberg
2024-03-21 3:06 ` Jirong Feng
2024-04-07 22:28 ` Sagi Grimberg
2024-04-12 7:52 ` Jirong Feng
2024-04-12 8:57 ` Sagi Grimberg
2024-04-22 9:47 ` Sagi Grimberg
2024-04-23 3:15 ` Jirong Feng
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=20240131062526.GA16177@lst.de \
--to=hch@lst.de \
--cc=axboe@fb.com \
--cc=jirong.feng@easystack.cn \
--cc=kbusch@kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=peng.xiao@easystack.cn \
--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