On Fri, 2013-10-04 at 15:02 +0000, KY Srinivasan wrote: > > > -----Original Message----- > > From: Eric Seppanen [mailto:eric@xxxxxxxxxxxxxxx] > > Sent: Thursday, October 03, 2013 1:49 PM > > To: Nicholas A. Bellinger > > Cc: KY Srinivasan; linux-kernel@xxxxxxxxxxxxxxx; devel@xxxxxxxxxxxxxxxxxxxxxx; > > linux-scsi@xxxxxxxxxxxxxxx > > Subject: Re: Drivers: scsi: FLUSH timeout > > > > On Thu, Oct 3, 2013 at 5:09 AM, Nicholas A. Bellinger > > <nab@xxxxxxxxxxxxxxx> 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. > > I like this idea and would result in minimal changes. James, if it ok with you, > I could send you the patch. Depends: I still prefer the per-target override, but if the proposal is to take the existing variable timeout for the queue and have 2x that for the flush, so you plan to increase the per-device timeout with hyper-v to 90s via sysfs, then I'm OK with it. James -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
