From: Ewan Milne <emilne@redhat.com>
To: Eric Seppanen <eric@purestorage.com>
Cc: "devel@linuxdriverproject.org" <devel@linuxdriverproject.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Nicholas A. Bellinger" <nab@linux-iscsi.org>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>
Subject: Re: Drivers: scsi: FLUSH timeout
Date: Fri, 04 Oct 2013 08:18:56 -0400 [thread overview]
Message-ID: <1380889136.4010.313.camel@localhost.localdomain> (raw)
In-Reply-To: <CADOQvuPWaSntci+4pNCbsP-Ug6P=xf1_5ZqqoaA+fXumgfHmeA@mail.gmail.com>
On Thu, 2013-10-03 at 13:48 -0700, Eric Seppanen wrote:
> On Thu, Oct 3, 2013 at 5:09 AM, Nicholas A. Bellinger
> <nab@linux-iscsi.org> wrote:
> >
> > On Wed, 2013-10-02 at 18:29 +0000, KY Srinivasan wrote:
> > > Ideally, I want this to be adjustable like the way we can change the I/O timeout.
> > > Since that has been attempted earlier and rejected (not clear what the reasons were),
> > > I was suggesting that we pick a larger number. James, let me know how I should proceed here.
> > >
> >
> > I think the objection was to making a module parameter for doing this
> > globally for all struct scsi_disk, and not the idea of making it
> > adjustable on an individual basis per-say..
> >
> > What about adding a /sys/class/scsi_disk/$HCTL/flush_timeout..?
>
> Do I/O timeouts and flush timeouts need to be independently adjusted?
> If you're having trouble with slow operations, it seems likely to be
> across the board.
>
> Flush timeout could be defined as 2x the read/write timeout. Any
> other command-specific timeouts could be scaled the same way.
It seems to me that there isn't any reason to expect that the maximum
amount of time a device might take to perform various operations are
related by any coefficient. And, an HBA (particularly iSCSI or FC)
could very well have different device types connected at different
target IDs. So I think the flush timeout should be adjustable on
a per-device basis. It's probably related more to the cache size
on the device than anything else...
Also note that there is a SD_WRITE_SAME_TIMEOUT value that is currently
4x the default SD_TIMEOUT value. That should probably be adjustable
as well.
-Ewan
next prev parent reply other threads:[~2013-10-04 12:18 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-20 19:32 Drivers: scsi: FLUSH timeout K. Y. Srinivasan
2013-09-20 20:32 ` Greg KH
2013-09-20 21:00 ` Laurence Oberman
2013-09-21 5:24 ` KY Srinivasan
2013-09-24 12:08 ` Jack Wang
2013-09-24 12:35 ` KY Srinivasan
2013-09-24 13:10 ` Bernd Schubert
2013-09-24 17:20 ` Mike Christie
2013-09-24 21:53 ` KY Srinivasan
2013-09-25 8:40 ` Geert Uytterhoeven
2013-10-02 18:29 ` KY Srinivasan
2013-10-03 12:09 ` Nicholas A. Bellinger
2013-10-03 14:13 ` KY Srinivasan
2013-10-03 20:48 ` Eric Seppanen
2013-10-04 12:18 ` Ewan Milne [this message]
2013-10-04 18:12 ` Eric Seppanen
2013-10-04 15:02 ` KY Srinivasan
2013-10-04 16:27 ` James Bottomley
2013-10-03 14:01 ` James Bottomley
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=1380889136.4010.313.camel@localhost.localdomain \
--to=emilne@redhat.com \
--cc=devel@linuxdriverproject.org \
--cc=eric@purestorage.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=nab@linux-iscsi.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).