[LSF/MM/BFP TOPIC] Block-layer device resets
Hannes Reinecke
hare at suse.de
Tue Feb 3 17:50:03 PST 2026
On 2/4/26 02:14, Ming Lei wrote:
> On Tue, Feb 03, 2026 at 06:51:25AM +0100, Hannes Reinecke wrote:
>> On 2/3/26 04:14, Ming Lei wrote:
>>> Hi Hannes,
>>>
>>> On Sun, Feb 01, 2026 at 06:06:52PM +0100, Hannes Reinecke wrote:
>>>> Hi all,
>>>>
>>>> We are currently working on implementing cross-controller resets for
>>>> NVMe, which requires to send a command to the target which then should
>>>> terminate all commands on a given controller.
>>>
>>> Can you provide a little background why this reset is required? And for
>>> solve which problem?
>>>
>> Sure. It got triggered by me wanting to use a ublk device as a backing
>> device for nvmet namespace.
>
> ublk supports it, either delete & re-add the disk or use UBLK_F_USER_RECOVERY &
> UBLK_F_QUIESCE for keeping disk node.
>
>> During a nvme reconnect the target is supposed to abort/flush all
>> outstanding commands on the backing device. As this is a block device
>> we would need to have an interface into the block layer allowing us
>> to do so.
>
> It could be hard to provide such generic(ioctl) block interface:
>
> 1) use queue freeze
>
> - hang risk, because some or many block devices don't implement timeout or
> error handling
>
> 2) use queue quiesce
>
> - still need driver cooperation for draining the inflight IOs
>
> Basically the hard part is in driver side.
>
Exactly. If there are drivers which do not implement a timeout handler
we're kinda screwed. But for those we should not implement a device
reset function, or rather return an error when that function is called.
For all others invoking the timeout handler on all outstanding commands
(and waiting for completions) would be equivalent to a device reset;
for some implementations (like NVMe) is _is_ equivalent to a device reset.
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare at suse.de +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich
More information about the Linux-nvme
mailing list