On 11/10/20 12:28 AM, Sagi Grimberg wrote:
[ .. ]
Originally nvme multipath would update/change the size of the multipath
device according to the underlying path devices.
With this patch the size of the multipath device will _not_ change
if there
is a change on the underlying devices.
Yes, it will. Take a close look at nvme_update_disk_info and how it is
called.
Okay, then: What would be the correct way of handling a size update
for NVMe multipath?
Assuming we're getting an AEN for each path signalling the size change
(or a controller reset leading to a size change).
So if we're updating the size of the multipath device together with
the path device at the first AEN/reset we'll end up with the other
paths having a different size than the multipath device (and the path
we've just been updating).
- Do we care, or cross fingers and hope for the best?
- Shouldn't we detect the case where we won't get a size update for
the other paths, or, indeed, we have a genuine device size mismatch
due to a misconfiguration on the target?
IE shouldn't we have a flag 'size update pending' for the other
paths,, to take them out ouf use temporarily until the other
AENs/resets have been processed?
the mpath device will take the minimum size from all the paths, that is
what blk_stack_limits does. When the AEN for all the paths will arrive
the mpath size will update.
But that's precisely my point; there won't be an AEN for _all_ paths,
but rather one AEN per path. Which will be processed separately, leading
to the issue described above.
Not sure how this is different than what we have today...
Oh, that is a problem even today.
So we should probably move it to a different thread...
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@xxxxxxx +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer
