[16:18:18] *** Joins: ziyeyang_ (ziyeyang@nat/intel/x-dxlwzegmakejqccb) [16:22:54] *** Joins: Shuhei (caf6fc61@gateway/web/freenode/ip.202.246.252.97) [16:35:27] *** Quits: ziyeyang_ (ziyeyang@nat/intel/x-dxlwzegmakejqccb) (Remote host closed the connection) [16:35:49] *** Joins: ziyeyang_ (~ziyeyang@134.134.139.74) [17:59:42] *** Quits: ziyeyang_ (~ziyeyang@134.134.139.74) (Quit: Leaving) [18:16:19] Hi Ziye, Jim, I posted a proposal as https://review.gerrithub.io/#/c/388334/. [18:17:01] This proposal is to abort any task found in the lun->tasks list unexpectedly when LUN_RESET is executed. [18:17:31] Please take a look at it when you are available. Thank you. [21:43:37] *** Joins: ziyeyang_ (ziyeyang@nat/intel/x-eqshrztdriodukou) [21:45:13] Hi Shuhei, abort any tasks found in the lun->tasks [21:46:18] should use the mechanism in this patch https://review.gerrithub.io/#/c/386817/ [21:53:26] I hope this make sense for you. [21:59:10] Hi Ziye, thank you for your feedback. I will reply to GerritHub too. If your approach to RAS is common sense in SPDK, of course I will follow that but I think which approach is better is not authorized yet. [22:00:24] Or in I/O world, needless to say that your approach is common? [22:03:50] Hi shuhei: My concern is that: If those scsi tasks are executed in bdev layer, it is asynchronous. And if reset is failed, those I/Os must generate completion event [22:04:05] And thus, we can recycle the resources. [22:04:43] If we directly remove those tasks in the iscsi front-end, how do we release the resources (i.e., bdev_io) in bdev layer [22:14:22] I learned a lot, thank you. [22:27:23] Hi Shuhei, In my mind, the exceptional handling will happen in a low priority in the real case. If it happen, will prove the issue for the backend bdev. I think that the AIO case (will be fixed by Cunyin') is an example [22:40:08] Hi Shuhei, I will rebase https://review.gerrithub.io/#/c/386817/ absorb your idea and submit it again [22:56:38] *** Joins: baruch (~baruch@141.226.177.138)