Comment 31 for bug 1778844

So, the hidden disk was introduced by hch as commit 8ddcd653257c18a669fcb75ee42c37054908e0d6 just to support nvme multipath. This thing prevented lsblk from working when there were slaves under the multipath nvme, as lsblk would postpone processing those, and lsblk could not process the paths themselves, because they have no dev_t.

Some discussion about reverting that slaves/holders patch is under the revert submission, and they decided to go on with the revert and think about how to fix that later. A link for one of the discussion messages is below.

https://www.spinics.net/lists/stable/msg222846.html

Going forward, we could either use nvme cli, embed the assumption that kernel won't change and some of the numbers are kept (like the subsys instance is embedded in both the multipath device and the underlying devices), or introduce this new paths subdir in the kernel. Any of those solutions would require changes to initramfs-tools. The latter would require a kernel change.

The only way of not changing initramfs-tools is going back to using slaves relationships. That means we would need to get rid of the hidden disks thing. This always worked for dm-multipath, but I believe this required some use of blkdev and that is one thing hch wanted to avoid, to have a very fast path for doing multipath.

I don't like the idea of using nvme cli that much, as it would be a hard dependency on initramfs-tools. I don't like assuming some of the implementation details on the kernel numbering/naming of those devices. So, I will take a stab at providing the paths interface.

Cascardo.