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