From: Minwoo Im <minwoo.im.dev@gmail.com>
To: Christoph Hellwig <hch@lst.de>
Cc: "Niklas Cassel" <Niklas.Cassel@wdc.com>,
"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
"Keith Busch" <kbusch@kernel.org>, "Jens Axboe" <axboe@fb.com>,
"Sagi Grimberg" <sagi@grimberg.me>,
"Kanchan Joshi" <joshiiitr@gmail.com>,
"Javier González" <javier.gonz@samsung.com>
Subject: Re: [PATCH V2 0/1] nvme: introduce generic per-namespace chardev
Date: Wed, 7 Apr 2021 01:23:09 +0900 [thread overview]
Message-ID: <20210406162309.GA165675@localhost> (raw)
In-Reply-To: <20210406145948.GB7790@lst.de>
On 21-04-06 16:59:48, Christoph Hellwig wrote:
> On Tue, Apr 06, 2021 at 10:35:33PM +0900, Minwoo Im wrote:
> > > with e.g. fdisk, mkfs, mount, in fstab, what to specify in fstab, etc.
> > >
> > > I think that there is value in reducing the confusion for regular users.
> >
> > Agreed on this point. We might have thousands of namespaces and it
> > might be making confusions to users.
>
> How does this create a confusion that it doesn't for the existing NVMe
> block devices and the SCSI disk and generic devices?
Okay. As there's sg device for SCSI, nvme-generic makes sense not to be
confusions.
> Morover: why would anyone want to expose these huge numbers of
> namespaces to a single host? While larger LUN counts in SCSI are
> sometimes needed for scalability reasons they aren't in NVMe. I haven't
> actually seen 4 digit namespace counts in NVMe except in synthetic
> test setups yet.
Sorry for talking about what I have not really seen ever. Thought about
this one in case that might be. :-)
> > > 2) Only create the new per-ns char dev for namespaces that were rejected.
> >
> > I prefer this one which is the major reason of this patch series being
> > posted.
>
> Which doesn't allow us to write portable programs just using the
> char node, as now a kernel upgrade that supports a new namespace type
> or feature will remove the char dev. It also is very different from
> what people expect from their SCSI and ATA setups.
Got your point.
Thanks for your feedback on this!
And here's another questions for your opinions.
In this new series, we have created nvme generic chardev along with the
block device(e.g., nvme0n1) which is not path-specific (e..g,
nvme0c0n1) in case of multipath. I think now we can say that it
supports multi-path. What do you say about this :) ?
Thanks!
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
next prev parent reply other threads:[~2021-04-06 16:23 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-06 6:48 [PATCH V2 0/1] nvme: introduce generic per-namespace chardev Minwoo Im
2021-04-06 6:48 ` [PATCH V2 1/1] " Minwoo Im
2021-04-07 13:15 ` Christoph Hellwig
2021-04-07 14:11 ` Minwoo Im
2021-04-07 14:21 ` Christoph Hellwig
2021-04-07 15:35 ` Minwoo Im
2021-04-07 15:40 ` Christoph Hellwig
2021-04-07 15:44 ` Minwoo Im
2021-04-07 15:47 ` Minwoo Im
2021-04-07 16:48 ` Christoph Hellwig
2021-04-07 16:59 ` Minwoo Im
2021-04-07 17:09 ` Minwoo Im
2021-04-07 17:14 ` Christoph Hellwig
2021-04-08 7:11 ` Javier González
2021-04-08 7:26 ` Christoph Hellwig
2021-04-08 10:26 ` Javier González
2021-04-08 11:27 ` Christoph Hellwig
2021-04-08 11:46 ` Javier González
2021-04-08 12:41 ` Minwoo Im
2021-04-06 9:01 ` [PATCH V2 0/1] " Niklas Cassel
2021-04-06 13:35 ` Minwoo Im
2021-04-06 14:59 ` Christoph Hellwig
2021-04-06 16:23 ` Minwoo Im [this message]
2021-04-07 6:00 ` Christoph Hellwig
2021-04-07 6:02 ` Minwoo Im
2021-04-07 7:36 ` Niklas Cassel
2021-04-07 9:39 ` Christoph Hellwig
2021-04-07 10:00 ` Niklas Cassel
2021-04-07 10:34 ` Damien Le Moal
2021-04-07 11:50 ` Javier González
2021-04-06 14:13 ` Kanchan Joshi
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=20210406162309.GA165675@localhost \
--to=minwoo.im.dev@gmail.com \
--cc=Niklas.Cassel@wdc.com \
--cc=axboe@fb.com \
--cc=hch@lst.de \
--cc=javier.gonz@samsung.com \
--cc=joshiiitr@gmail.com \
--cc=kbusch@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