[PATCH V2 0/1] nvme: introduce generic per-namespace chardev

[Minwoo Im]

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!