[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 ?