From: Luben Tuikov <luben_tuikov@adaptec.com>
To: Mike Anderson <andmike@us.ibm.com>
Cc: James Bottomley <James.Bottomley@steeleye.com>,
SCSI Mailing List <linux-scsi@vger.kernel.org>
Subject: Re: [PATCH]: Flexible timeout infrastructure
Date: Tue, 15 Jun 2004 18:00:49 -0400 [thread overview]
Message-ID: <40CF7191.3020703@adaptec.com> (raw)
In-Reply-To: <20040615205715.GB13704@us.ibm.com>
> The patch is adding an interface that adds two capabilities. A LLDD
> callout to possibly handle timed out commands and another capability to
> control when command timers start / stop.
Yes, I know -- I wrote it. ;-)
> If a LLDD wanted to just get called to possibly handle timed out
> commands it must also take care of starting and stopping command timers.
> This is all I was saying in the previous comment.
Yes, it does take care of that -- see my comment before
int (* eh_cmd_timed_out)(struct scsi_cmnd *);
> Why does the LLDD not have to consult the same information that the SCSI
Because
1. It's closed to the hardware/LU than SCSI Core is.
2. Because this is NOT the SAM interface. See SAM TMF.
SCSI Core calls a TMF telling LU via LLDD what to do.
LLDD doesn't consult each and every time SCSI Core what to do.
It's a suble difference, but a difference nevertheless.
> mid layer does on retries (i.e., scmd->allowed, blk_noretry_request). Is
> there no idempotent issue to worry about? While SPI topologies may lead
> to LLDD retries being successful in completing the command a major of
> the time, there are other transport topologies that lead to the success
> of the IO only through the re-driving of the IO through a disjoint path
> (i.e., different LLDD instance, port, etc.) which would be done outside
> the scope of the LLDD.
And, _again_, the LLDD would *know* about and can return EH_NONE, to
have SCSI Core/Application client try another path.
> >
> > That is, if IO is NOT to be continued, then SCSI Core should call
> > a TMF, ABORT TASK or ABORT TASK SET, via eh_abort_handler(<cmd>).
> > (Yes, the eh interface doesn't do 1:1 TMF mapping.)
> >
>
> The scsi mid layer would only call the eh_abort_handler post a timeout
> event (there are other rare case in scsi_decide_disposition that wake
The reason for calling TMF ABORT TASK is beyond the point, whether it be
timeout of application client failure. The importance is the mechanism.
> the error handler) which is being handled by the eh_cmd_timed_out
> function of the LLDD so there would be no way for the scsi mid layer to
> abort the IO.
There is: call the appropriate TMF.
We need to implement TMF ABORT TASK entry, et al, into SCSI Core
and into LLDD, as TMF are Application Client --> SCSI transport.
> I think the template callout in scsi_times_out is good. I believe there
> is still debate on controlling the timers that is why I suggested maybe
> the two capabilities could be separated.
I'm rather opposed to another separation, as this bloats up SCSI Core
and makes it more complicated, unecessarily so. scsi_done() and
queuecommand() are quite simple an interface currently and I'd
rather keep it like that.
> I believe the callout as per my previous query last week may help in
> some failover / failback case involing device mapper multipath. I
> think it would be good for SCSI core to have this callout interface or
> one like it.
>
> -andmike
> --
> Michael Anderson
> andmike@us.ibm.com
>
--
Luben
next prev parent reply other threads:[~2004-06-15 22:00 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-15 15:02 [PATCH]: Flexible timeout infrastructure Luben Tuikov
2004-06-15 15:08 ` Signed-off-by: added [Re: [PATCH]: Flexible timeout infrastructure] Luben Tuikov
2004-06-15 15:24 ` Matthew Wilcox
2004-06-15 15:27 ` [PATCH]: Flexible timeout infrastructure Arjan van de Ven
2004-06-15 15:40 ` Luben Tuikov
2004-06-15 15:42 ` Christoph Hellwig
2004-06-15 15:46 ` Luben Tuikov
2004-06-15 15:49 ` Christoph Hellwig
2004-06-15 15:43 ` Arjan van de Ven
2004-06-15 15:48 ` Luben Tuikov
2004-06-15 15:57 ` Christoph Hellwig
2004-06-15 16:07 ` Arjan van de Ven
2004-06-15 16:24 ` Doug Ledford
2004-06-15 16:27 ` Luben Tuikov
2004-06-15 16:33 ` Arjan van de Ven
2004-06-15 18:07 ` Luben Tuikov
2004-06-15 15:31 ` James Bottomley
2004-06-15 18:15 ` Mike Anderson
2004-06-15 18:37 ` Luben Tuikov
2004-06-15 19:20 ` Mike Anderson
2004-06-15 19:52 ` Luben Tuikov
2004-06-15 20:57 ` Mike Anderson
2004-06-15 22:00 ` Luben Tuikov [this message]
2004-06-15 22:31 ` Luben Tuikov
2004-06-15 22:13 ` Doug Ledford
2004-06-15 19:12 ` Luben Tuikov
2004-06-15 19:54 ` James Bottomley
2004-06-16 15:27 ` Mike Anderson
2004-06-16 15:37 ` James Bottomley
2004-06-16 15:48 ` Luben Tuikov
2004-06-16 15:58 ` James Bottomley
-- strict thread matches above, loose matches on Subject: below --
2004-06-16 16:58 Smart, James
2004-06-16 17:04 ` James Bottomley
2004-06-16 18:58 ` Luben Tuikov
2004-06-16 19:17 ` James Bottomley
2004-06-16 17:10 Smart, James
2004-06-16 17:21 ` James Bottomley
2004-06-16 17:33 Smart, James
2004-06-16 17:38 ` James Bottomley
2004-06-16 18:05 Smart, James
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=40CF7191.3020703@adaptec.com \
--to=luben_tuikov@adaptec.com \
--cc=James.Bottomley@steeleye.com \
--cc=andmike@us.ibm.com \
--cc=linux-scsi@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.