Re: [PATCH 03/24] nvme: let set_capacity_revalidate_and_notify update the bdev size

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




[ .. ]
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.

Not sure how this is different than what we have today...



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]

  Powered by Linux