From mboxrd@z Thu Jan 1 00:00:00 1970 From: keith.busch@intel.com (Keith Busch) Date: Mon, 29 Oct 2018 09:55:07 -0600 Subject: [PATCH 2/2] nvme/multipath: Fix multipath disabled naming collisions In-Reply-To: References: <20180426214956.3377-1-keith.busch@intel.com> <20180426214956.3377-3-keith.busch@intel.com> <20181029154229.GA16586@localhost.localdomain> Message-ID: <20181029155506.GA16595@localhost.localdomain> On Mon, Oct 29, 2018@03:48:52PM +0000, Stephen Bates wrote: > > > Note how the /nvme/nvme0/ sysfs directory contains the nvme1n1 > > > namespace. Is this expected? I am not that familiar with the multipath > > > code so I'm not sure if this is a bug or not but it sure is confusing. > > > Disabling CONFIG_NVME_MULTIPATH reverts to the legacy naming > > > convention. This happens in all the 4.19, 4.18 and 4.17 kernels we > > > tested. I've not tried the for-next tree. > > > > That is expected. We still need character devices to each controller path > > for administration, but we don't need block devices to each namespace > > path, so the numbers in the controller and block handles are independent > > of each other. > > Keith > > Ooooookay. Thanks for letting us know! Note the naming convention that's causing confusion applies to the visible namespace paths. The hidden paths have naming convention like "nvmecn", and that value matches up the the controller handle at /dev/nvme. That doesn't do you any good if you're looking in /dev/ since those paths are hidden, but the topology can be observed in /sys/.