Re: [Qemu-block] RFC block/iscsi command timeout

[Kevin Wolf]

Am 26.05.2015 um 11:30 hat Peter Lieven geschrieben:
> Am 26.05.2015 um 11:01 schrieb Kevin Wolf:
> >Am 22.05.2015 um 09:30 hat Peter Lieven geschrieben:
> >>Hi,
> >>
> >>next libiscsi version will allow to define command timeouts. At least for 
> >>sync commands this
> >>was in fact possible since somewhen in 2013. Per default this timeout is 
> >>disabled.
> >>
> >>I would like to at least define a timeout for the sync commands (login, 
> >>readcapacity, inquiry, logout etc)
> >>of about 5000msec.
> >You should probably make the timeout an integer option rather than a
> >boolean one. Then we don't need to discuss whether 5000 msec are
> >appropriate...
> >
> >>The chance to the iSCSI driver of qemu would be minimal for that. The 
> >>timeout
> >>handling is done in the sync event loop of libiscsi.
> >>
> >>My question is if it would be a good idea to have timeout (fairly high of 
> >>course) for all other commands as well?
> >...and what "fairly high" actually means.
> 
> Following your idea to introduce an option I would do the following:
> 
> Default:
>  sync commands: 5000msec (this should be far, far enough for login, logout, 
> etc.) These are all calls in iscsi_open / iscsi_close, not called during 
> normal operation.
>  async commands: no timeout
> 
> Secifying a timeout will then set the timeout for sync and async commands with
> the option to specify 0 to disable timeouts at all.
> 
> If we run into a timeout we theoretically have the following options:
>  - reconnect
>  - retry
>  - error
> 
> I would reconnect as Ronnie proposed.

Just trying to reconnect indefinitely might not be the best option.
Consider the situation where you're inside a bdrv_drain_all(), which
blocks qemu completely. Trying to reconnect once or twice is probably
fine, but if that doesn't work, eventually you want to return an error
so that qemu is unstuck.

Kevin