nvme/pcie hot plug results in /dev name change
Sagi Grimberg
sagi at grimberg.me
Wed Feb 15 00:56:49 PST 2023
>>> Isn't this equivalent to dm-mpath queue_if_no_path or no_path_timeout ?
>>
>> Similiar, but generic to non-multipath devices.
>
> Exactly!
>
>>> We can keep the mpath device around, but if not, what is the desired
>>> behavior from the upper layers?
>>
>> I don't think we're looking for any behavioral changes in the upper layers.
>
> There's really two different things, which would both a problem:
>
> - make the device not go away if we expect it to come back by using
> the multipath code
How do you know in the driver what to expect? how can anyone know
what to expect? There is also a question of what to do with the
I/O coming in, queue it or fail it and when...
> - tell the upper layer that a devie went away when it actually did
Don't we already send a udev event KOBJ_REMOVE when a block device goes
away?
IIRC LVM already removes its stuff if the underlying block device
goes away (although I do recall that the dm did leave the device
handle open)...
> Right now if user has a block device open, it will keep a reference to
> it forever. If we send a notification to the upper layer not only can
> it release that refrence, but it also knows the device went away.
--
KERNEL[520130.230115] remove /devices/virtual/bdi/252:0 (bdi)
KERNEL[520130.230261] remove /devices/virtual/block/nullb0 (block)
--
> This really helps to e.g. rebalance data in a RAID or RAID-like setup.
I thought that RAID already tracked these sort of events...
More information about the Linux-nvme
mailing list