[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1380808905.2109.7.camel@dabdike.int.hansenpartnership.com>
Date: Thu, 3 Oct 2013 14:01:45 +0000
From: James Bottomley <jbottomley@...allels.com>
To: KY Srinivasan <kys@...rosoft.com>
CC: Geert Uytterhoeven <geert@...ux-m68k.org>,
Mike Christie <michaelc@...wisc.edu>,
Jack Wang <xjtuwjp@...il.com>,
Greg KH <gregkh@...uxfoundation.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"devel@...uxdriverproject.org" <devel@...uxdriverproject.org>,
"ohering@...e.com" <ohering@...e.com>,
"hch@...radead.org" <hch@...radead.org>,
"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>
Subject: Re: Drivers: scsi: FLUSH timeout
On Wed, 2013-10-02 at 18:29 +0000, KY Srinivasan wrote:
>
> > -----Original Message-----
> > From: geert.uytterhoeven@...il.com [mailto:geert.uytterhoeven@...il.com]
> > On Behalf Of Geert Uytterhoeven
> > Sent: Wednesday, September 25, 2013 1:40 AM
> > To: KY Srinivasan
> > Cc: Mike Christie; Jack Wang; Greg KH; linux-kernel@...r.kernel.org;
> > devel@...uxdriverproject.org; ohering@...e.com; jbottomley@...allels.com;
> > hch@...radead.org; linux-scsi@...r.kernel.org
> > Subject: Re: Drivers: scsi: FLUSH timeout
> >
> > On Tue, Sep 24, 2013 at 11:53 PM, KY Srinivasan <kys@...rosoft.com> wrote:
> > > I am not sure how that magic number was arrived at (the 60HZ number). We
> > want this to be little higher -
> >
> > "60 * HZ" means "60 seconds".
> >
> > > would there be any issues raising this to say 180 seconds. This is the value we
> > currently have for I/O
> > > timeout.
> >
> > So you want to replace it by "180 * HZ", which is ... another magic number?
>
> 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.
It's only one problem device with its own driver, right? how about a
per target value you set in target_configure? That way there's no
damage to the rest of the system even in a mixed device environment. I
don't see a particular need to expose this via sysfs unless someone else
has a use case.
James
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists