[WIP] udiskslinuxdrive: Calculate drive size from all attached NVMe namespaces

[tbzatek]

In case capacity reporting is not supported by the NVMe controller, calculate the drive size from the currently attached namespaces as a workaround.

This presents a chicken-egg problem when not all block objects are present at the time the drive size calculation is done. So ping the drive object back once a namespace interface is published, and on all subsequent uevents (e.g. as a result of LBA format change). Since the pingback is queued in the main loop, the drive Size property gets updates slightly later.

Fixes #1194

TODO:

• [ ] handle namespace detach (uevent remove) event

[BrainBlasted]

We hit this issue upstream in GNOME with our testing system (GNOME OS). Applying this patch seems to fix the issue.

[seb128]

@tbzatek in case extra feedback is helping, we put that patch in a ppa for Ubuntu and got some users confirming it's working for them (https://bugs.launchpad.net/udisks/+bug/2038761).

Since it's an issue which is often raised by our users I will go ahead and apply it also as a distro patch in our devel serie now. Is there anything we can do to help getting that work landed upstream?

[tbzatek]

Thanks Sebastien, this is a useful feedback. As long as consumer-level NVMe drives typically expose just a single namespace, we need to make sure this approach works for drives that offer namespace management and for NVMe over Fabrics-connected resources.

I still need to rework the patch to make it less hacky and make use of finer-granularity object hooks (#1233), however the way of size computation wouldn't likely change. Feel free to ship the patch for the moment.

[mrhpearson]

Just a note that we've been hitting this issue on some of the Lenovo laptops in our Linux program (it shows up in our QA process, and causes some headaches in our manufacturing preload process that we've worked around).

It does depend on the SSD vendor being used, so we're going to follow up with the vendors to see what can be fixed there - but I think having it addressed in udisks would be good and help future proof things.

As this PR is a WIP - are there any recommendations on what we can do to help move this forward?

We've tested the commit on a number of platforms and it fixes the issue. So far haven't seen any side effects. Let me know how we can help move this forward

Thanks Mark

[Nanome203]

Any updates on this ?

[mrhpearson]

A note that we confirmed with the vendor that it's SSDs that don't support namespace management (NVMCAP is set to 0) namespaces that aren't working.

@tbzatek - let me know what we can do to help get this issue wrapped up as it seems close to complete. Happy to help with any testing etc if that would be useful.

[tbzatek]

So one of the pre-requsites for completing this work is to create test cases for our d-bus test suite. Specifically we need to test namespace attach and detach events and verify that the reported controller object capacity has changed accordingly. Not many devices do support namespace management, neither the kernel nvmet target, as controlled from the initiator side.

However turned out the nvmet target allows enabling/disabling particular namespaces through configfs, e.g.

# echo 0 > /sys/kernel/config/nvmet/subsystems/nqn.2014-08.org.nvmexpress.boot.poc:test-target/namespaces/202/enable 

and the host nvme driver on the initiator side would react on such events:

nvme nvme2: rescanning namespaces.

Tested cross-network with the tcp transport, needs to be tested and implemented for single-machine scenario through the loop transport that we do use in our test suite.

Anyway, quick test of the current state of the PR reveals that namespace detach events are not registered properly, leading to incorrect capacity reporting.