Re: ublk: Graceful Upgrade of ublk server application

[Ming Lei <ming.lei@redhat.com>]

On Tue, Apr 15, 2025 at 06:51:57PM -0600, Uday Shankar wrote:
> On Tue, Apr 15, 2025 at 07:46:51PM +0000, Yoav Cohen wrote:
> > Hi Ming,
> > 
> > Thank you for the fast reply.

oops, looks I didn't get your reply, :-(

> > To be clear, I don't want calling DELETE_DEV or STOP_DEV as I want the kernel bdev will be stay while upgrading the ublk server application.

Can you explain a bit what is upgrading? Is it simple application binary
replacement?

> > It would be nice to have a nice way to have something like FREEZE_DEV that we may use which will also make all the cmds back with ABORT result but both block and char device will be stay until a new userspace application will reconnect.
> 

Looks one reasonable requirement, maybe SUSPEND_DEV and RESUME_DEV command,
which exists on RAID/DM too.

Also when device is in (new)suspended state, parameter can be re-configured.

Most of recover code can be reused, in theory it shouldn't be hard to
support, but one trouble could be what if both uring exiting and SUSPEND_DEV
happen at the same time? This corner case need to be take into account. 

I'd suggest to cover more requirements given it should be one generic
interface.

> Have you taken a look at the recovery flags? These offer slightly
> different behaviors around how I/O is handled while the ublk server is
> dying/when it is dead, but they all keep the block device up even after
> the ublk server exits.
> 
> The flags are documented at https://docs.kernel.org/block/ublk.html

The recovery mechanism is triggered passively, and here the upgrading
needs to suspend device voluntarily & gracefully.

Maybe add one control command of COOP_CANCEL_FOR_RECOVERY or ABORT_URING_CMD
to abort active uring_cmd for triggering recovery from userspace? Which looks
much easier. But it need cooperation between ublk driver and server.


Thanks,
Ming