From: Tejun Heo <htejun@gmail.com>
To: Kai Makisara <Kai.Makisara@kolumbus.fi>
Cc: James.Bottomley@SteelEye.com, linux-scsi@vger.kernel.org
Subject: Re: [PATCH RESEND 2/2] SCSI: add scsi_device->retries
Date: Mon, 20 Nov 2006 08:31:28 +0900 [thread overview]
Message-ID: <4560E950.9000209@gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0611200001230.4946@kai.makisara.local>
Hello,
Kai Makisara wrote:
>> * st uses three retry limits - MAX_RETRIES, MAX_WRITE_RETRIES and
>> MAX_READY_RETRIES, which are all zero. This patch only converts
>> MAX_RETRIES to sdev->retries. Defining WRITE and READY retries in
>> terms of sdev->retries would make more sense.
>>
> I am neither acking nor naking this now. The patch does not change st
> behavior but moves part of the retry strategy out of the driver. (Which is
> also good because it makes one of the retry limits user changeable.)
>
> Combining all retry counts is something that may not be a good thing.
> Below is justification why st has three different retry limits.
>
> For some devices one number of retries is not perfect for all functions.
>
> The firmware of tape devices usually retries quite thoroughly before
> returning error. This is why the default zero applies to most cases.
>
> MAX_WRITE_RETRIES is separate from MAX_RETRIES because a plausible
> strategy might be (maybe not any more) to allow no retries for write but
> allow retries for reading and repositioning. The writes should fail
> directly so that the minimum number of marginal errors will be written.
> The reads can be retried so that even marginal data can be recovered.
> (Note that this may lead to tape positioning errors and may not be a
> good strategy in all cases.)
>
> MAX_READY_RETRIES is used for commands that don't move the tape. This is a
> situation where retrying is probably harmless.
I see. Then, how about adding and initializing STp->write_retries and
STp->ready_retries according to SDp->retries (some reasonable default
value, say write_retries is always zero while ready_retries is round up
of retries * 1.1) and export both through sysfs? That will give lower
level primitive control as other ULDs do and also allow users to
configure each timeout separately if necessary.
Thanks.
--
tejun
next prev parent reply other threads:[~2006-11-19 23:31 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-19 12:51 [PATCH RESEND 1/2] SCSI: use scsi_device->timeout consistently Tejun Heo
2006-11-19 12:52 ` [PATCH RESEND 2/2] SCSI: add scsi_device->retries Tejun Heo
2006-11-19 22:32 ` Kai Makisara
2006-11-19 23:31 ` Tejun Heo [this message]
2006-11-20 21:42 ` Kai Makisara
2006-11-19 22:01 ` [PATCH RESEND 1/2] SCSI: use scsi_device->timeout consistently Kai Makisara
2006-11-19 23:26 ` Tejun Heo
2006-11-20 21:25 ` Kai Makisara
2006-11-21 2:14 ` Tejun Heo
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=4560E950.9000209@gmail.com \
--to=htejun@gmail.com \
--cc=James.Bottomley@SteelEye.com \
--cc=Kai.Makisara@kolumbus.fi \
--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.