Am 22.05.2015 um 14:22 schrieb ronnie sahlberg:
On Fri, May 22, 2015 at 12:30 AM, Peter Lieven <p...@kamp.de <mailto:p...@kamp.de>> wrote: 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. Just to mention that this does not require any API changes or need to update library version requirements. It just require that the application will be calling iscsi_service(iscsi, 0) at regular intervals to trigger the timeout scans. On older versions of libiscsi, this will be a no-op, so situation is unchanged and timeouts may not work. On newer versions of libiscsi this will actually process the timeout scanning and cause the timeouts to actually happen. I would like to at least define a timeout for the sync commands (login, readcapacity, inquiry, logout etc) of about 5000msec. 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. Is the idea that when a timeout occurs, the callback will eventually trigger an attempt to tear down and reconnect the session? I think a lot of/most linux kernels (guests) have a default timeout that they will perform a full bus reset once a task has hung for 60 seconds. Thus a tmeout or <<60 seconds will give you a lot of time to do several attempts to bounce the session to the target and try to recover before it hits the guest.
The problem with a timeout for *ALL* commands is that we might execute a command (even from the guest) which may take a very long time. So, I think, the safe approach would be to set only timeouts at the sync commands first. Peter
