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

From: Christoph Hellwig <hch@lst.de>
To: Minwoo Im <minwoo.im.dev@gmail.com>
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>,
	"Christoph Hellwig" <hch@lst.de>,
	"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: Tue, 6 Apr 2021 16:59:48 +0200	[thread overview]
Message-ID: <20210406145948.GB7790@lst.de> (raw)
In-Reply-To: <20210406133533.GC2594@localhost>

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?

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.

> > 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.

_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme