Messages in this thread | | | Date | Thu, 22 Sep 2022 10:06:30 +0800 | Subject | Re: [PATCH V4 5/8] ublk_drv: consider recovery feature in aborting mechanism | From | Ziyang Zhang <> |
| |
On 2022/9/22 08:18, Ming Lei wrote: > On Wed, Sep 21, 2022 at 05:58:46PM +0800, ZiyangZhang wrote: >> With USER_RECOVERY feature enabled, the monitor_work schedules >> quiesce_work after finding a dying ubq_daemon. The monitor_work >> should also abort all rqs issued to userspace before the ubq_daemon is >> dying. The quiesce_work's job is to: >> (1) quiesce request queue. >> (2) check if there is any INFLIGHT rq. If so, we retry until all these >> rqs are requeued and become IDLE. These rqs should be requeued by >> ublk_queue_rq(), task work, io_uring fallback wq or monitor_work. >> (3) complete all ioucmds by calling io_uring_cmd_done(). We are safe to >> do so because no ioucmd can be referenced now. >> (5) set ub's state to UBLK_S_DEV_QUIESCED, which means we are ready for >> recovery. This state is exposed to userspace by GET_DEV_INFO. >> >> The driver can always handle STOP_DEV and cleanup everything no matter >> ub's state is LIVE or QUIESCED. After ub's state is UBLK_S_DEV_QUIESCED, >> user can recover with new process. >> >> Note: we do not change the default behavior with reocvery feature >> disabled. monitor_work still schedules stop_work and abort inflight >> rqs. And finally ublk_device is released. >> >> Signed-off-by: ZiyangZhang <ZiyangZhang@linux.alibaba.com> > > This version is close to be ready, just some debug logging needs > be removed, see inline comment. Also I'd suggest you to learn to > use bpftrace a bit, then basically you needn't to rely on kernel > logging. > > If these logging is removed, you will see how simple the patch becomes > compared with previous version.
Current version is simpler, thanks for reviewing, Ming. Debug logging will be removed in V5 and I will send it out soon.
Regards, Zhang
| |