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
