linux-kernel - RE: Drivers: scsi: FLUSH timeout

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 24 Sep 2013 21:53:00 +0000
From:	KY Srinivasan <kys@...rosoft.com>
To:	Mike Christie <michaelc@...wisc.edu>
CC:	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>,
	"jbottomley@...allels.com" <jbottomley@...allels.com>,
	"hch@...radead.org" <hch@...radead.org>,
	"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>
Subject: RE: Drivers: scsi: FLUSH timeout



> -----Original Message-----
> From: Mike Christie [mailto:michaelc@...wisc.edu]
> Sent: Tuesday, September 24, 2013 10:21 AM
> To: KY Srinivasan
> Cc: 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 09/24/2013 07:35 AM, KY Srinivasan wrote:
> >
> >
> >> -----Original Message-----
> >> From: Jack Wang [mailto:xjtuwjp@...il.com]
> >> Sent: Tuesday, September 24, 2013 5:08 AM
> >> To: KY Srinivasan
> >> Cc: Greg KH; linux-kernel@...r.kernel.org; devel@...uxdriverproject.org;
> >> ohering@...e.com; jbottomley@...allels.com; hch@...radead.org; linux-
> >> scsi@...r.kernel.org; Mike Christie
> >> Subject: Re: Drivers: scsi: FLUSH timeout
> >>
> >> On 09/21/2013 07:24 AM, KY Srinivasan wrote:
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Greg KH [mailto:gregkh@...uxfoundation.org]
> >>>> Sent: Friday, September 20, 2013 1:32 PM
> >>>> To: KY Srinivasan
> >>>> Cc: 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 Fri, Sep 20, 2013 at 12:32:27PM -0700, K. Y. Srinivasan wrote:
> >>>>> The SD_FLUSH_TIMEOUT value is currently hardcoded.
> >>>>
> >>>> Hardcoded where?  Please, more context.
> >>>
> >>> This is defined in scsi/sd.h:
> >>>
> >>> #define SD_FLUSH_TIMEOUT        (60 * HZ)
> >>>>
> >>>>> On our cloud, we sometimes hit this timeout. I was wondering if we
> >>>>> could make this a module parameter. If this is acceptable, I can send
> >>>>> you a patch for this.
> >>>>
> >>>> A module parameter don't make sense for a per-device value, does it?
> >>> Currently, the 60 second timeout is applied across devices. Ideally, I want to
> be
> >>> able to control the FLUSH TIMEOUT as we currently do I/O timeout. If this is
> >>> acceptable, I can work on a patch for that as well.
> >>>
> >>> Regards,
> >>>
> >>> K. Y
> >>>>
> >>>> greg k-h
> >>> --
> >>> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> >>> the body of a message to majordomo@...r.kernel.org
> >>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >>>
> >> Hi,
> >>
> >> Back to 2010, Mike(cc-ed) try to add a flush time out interface, similar
> >> to what you want here, no idea why it's just ignored?
> >> http://www.spinics.net/lists/linux-scsi/msg45017.html
> >
> > Thanks Jack. Mike, do you know what the concerns were as to why this
> > patch was not accepted?
> >
> 
> I do not remember the exact concerns. We ended up just increasing the
> hard coded value in:
> 
> commit e3b3e6246726cd05950677ed843010b8e8c5884c
> Author: Mike Christie <mchristi@...hat.com>
> Date:   Wed Aug 11 11:06:25 2010 -0500
> 
>     [SCSI] scsi/block: increase flush/sync timeout
> 
> 
> In the git commit message there is a comment about people thinking
> making it configurable for users was troublesome.

I am not sure how that magic number was arrived at (the 60HZ number). We want this to be little higher -
would there be any issues raising this to say  180 seconds. This is the value we currently have for I/O
timeout.

Regards,

K. Y

--
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/