Re: [PATCH 1/4] libiscsi: Check TMF state before sending PDU

2009-08-14 Thread Hannes Reinecke
Mike Christie wrote: Hannes Reinecke wrote: Before we're trying to send a PDU we have to check whether a TMF is active. If so and if the PDU will be affected by the TMF we should allow only Data-out PDUs to be sent, or, if fast_abort is set, no PDUs at all. You sort of changed the

Re: [PATCH 3/4] libiscsi: Set the 'FINAL' bit to terminate data transfer on TMF

2009-08-14 Thread Hannes Reinecke
Mike Christie wrote: Hannes Reinecke wrote: Whenever we send a Data-Out response to an affected LUN during LU Reset, we should be setting the 'FINAL' bit. This will indicate to the target that we consider this transfer finished. Signed-off-by: Hannes Reinecke h...@suse.de ---

Re: [RFC] Dynamically adjust shost-can_queue

2009-08-14 Thread Hannes Reinecke
Mike Christie wrote: Mike Christie wrote: We were discussing this on the fcoe list, and I mentioned it here on the scsi cmd timer patch. What I thought we might want to do is instead of doing it based on cmdsn window rejects which can sometimes be static, we can take into account how

[PATCH] I/O stall finally solved

2009-08-14 Thread Hannes Reinecke
Hi Mike, finally I've found the mysterious I/O stall I've been chasing for the last two months. Problem is iscsi_conn_queue_work(); we're just calling queue_work() without checking the return value. However, queue_work() will be effectively a no-op when there is some work already running, so

Re: [RFC] Dynamically adjust shost-can_queue

2009-08-14 Thread Ulrich Windl
On 13 Aug 2009 at 16:34, Hannes Reinecke wrote: Interesting though, both NetApp and MSA level out at around 64 commands. Maybe we should consider changing the default ... Our old HP AutoRAID had a recommended queue depth of 8, but I don't know what the actual queue size was. At least at

Re: [RFC] Dynamically adjust shost-can_queue

2009-08-14 Thread Ulrich Windl
On 13 Aug 2009 at 10:33, Mike Christie wrote: + iscsi_session_printk(KERN_INFO, session, + adjusted queue depth to %u\n, + host-can_queue); For a real patch you probably want to make this a debug printk. We

Re: [PATCH 4/4] libiscsi: Flush workqueue before suspend

2009-08-14 Thread Ulrich Windl
On 13 Aug 2009 at 11:55, Mike Christie wrote: some additions: Mike Christie wrote: wait_on_commands() { while (check_restrictions(conn-task) session-state == LOGGED_IN) wait for a while wait for a while always looks like a design flaw to me.

Re: [PATCH 4/4] libiscsi: Flush workqueue before suspend

2009-08-14 Thread Hannes Reinecke
Ulrich Windl wrote: On 13 Aug 2009 at 11:55, Mike Christie wrote: some additions: Mike Christie wrote: wait_on_commands() { while (check_restrictions(conn-task) session-state == LOGGED_IN) wait for a while wait for a while always looks like a design