From: sim@linux.vnet.ibm.com (Narasimhan V)
Subject: [PATCH] nvme: avoid connecting to the same subsystem from the same path gain.
Date: Mon, 31 Jul 2017 20:11:59 +0530 [thread overview]
Message-ID: <be62cd00899ecf800cb2d2d9fd4267ab@linux.vnet.ibm.com> (raw)
In-Reply-To: <31fc10fb-386a-c430-4ca6-1a48e6b356d0@huawei.com>
On 2017-04-27 12:46, Guan Junxiong wrote:
> On 2017/4/27 14:40, Christoph Hellwig wrote:
>> On Tue, Apr 25, 2017@09:20:00AM +0800, Guan Junxiong wrote:
>>> Hi ,Christoph:
>>> What's the benefits of this feature? If we execute the following
>>> cmd
>>> 10 times, it will generate 10 character and at least 20 block
>>> devices.
>>
>> The number of block devices will depend on the number of namespaces
>> configured, but yes, this is expected. The NVMe architecture allows
>> for multiple connections from a given host to a subsystem.
>>
>> .
>>
> Hi, Christoph,Thanks for your reply!
>
> Currently, the number of block devices will depend on both the number
> of
> namespaces configured in a subsystem and the number of connections
> created by
> connect command.
>
> In addition , I still have the suggestion:
> Can this feature or problematic behavior be adjusted to prevent
> generating
> another block devices when a new connection is created from a given
> host to
> a subsystem via the same patho<\x1f Maybe a character device (controller)
> or
> block device (namespaces) can represent more connections given the same
> path.
>
> Looking forward for you response. Thanks.
Hellwig,
I think this is more of a confusing/problematic behaviour than a
feature, as stated.
We might connect to same subsystem again, and see a different nvme
subsystem, block devices.
Tools like fdisk will discover duplicate block devices as different
ones.
So, we might think it is a different subsystem. And thus, might have
data corruption issues.
Looking forward for your clarification in such scenarios, and probably
your take on this
being feature vs issue.
--
Regards
Narasimhan V
next prev parent reply other threads:[~2017-07-31 14:41 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-24 13:26 [PATCH] nvme: avoid connecting to the same subsystem from the same path gain Guan Junxiong
2017-04-24 14:58 ` Christoph Hellwig
2017-04-25 1:20 ` Guan Junxiong
2017-04-26 9:34 ` Guan Junxiong
2017-04-27 6:40 ` Christoph Hellwig
2017-04-27 7:16 ` Guan Junxiong
2017-07-31 14:41 ` Narasimhan V [this message]
2017-04-26 15:33 ` Guilherme G. Piccoli
2017-04-27 7:21 ` Guan Junxiong
2017-04-27 12:30 ` Guilherme G. Piccoli
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=be62cd00899ecf800cb2d2d9fd4267ab@linux.vnet.ibm.com \
--to=sim@linux.vnet.ibm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.