On Tuesday 20 April 2010, Mike Christie wrote: > On 04/20/2010 09:54 AM, Bernd Schubert wrote: > > On Tuesday 20 April 2010, Desai, Kashyap wrote: > >>>>>> all block device flushes or is this more device specific? I was > >>>>>> thinking that we may want to create a sysfs interface under the > >>> > >>> block > >>> > >>>>>> dirs and have blk-sysfs.c and blk-barrier.c handle this. > >>> > >>> queue_flush > >>> > >>>>>> could set the timeout and retries that is set by some new files > >>> > >>> under > >>> > >>>>>> /sys/block/sdX/queue/ ? > >> > >> Thanks a lot for your comments. > >> > >> This is very close to my understanding. I feel this is more close to > >> block layer and I am almost agreeing with your thought. I tried to > >> understand why upstream does not have retries at > >> queue_flush()/sd_prepare_flush() ??? It looks like there is not specific > >> reason. If I am wrong can someone explain is there any specific reason > >> not to set rq->retries in sd_prepare_flush? > > > > I don't understand why we should need another queue timeout, when we > > already have a device timeout that is used as queue timeout? > > I think a possible problem is that the one timeout setting is now being > used for two different operations. Currently, for disks that timeout is > used for READ/WRITEs. For the sync cache, if we are hitting a problem > with it taking longer than the current value of 30 secs, then could we > want to set the READ/WRITE timeout to a lower value like 60 secs, but > then the sync cache timeout might have to be multiple minutes. Hmm, I don't know storage systems where it might take several minutes, but sure, if a system has hundreds of gigabyte of cache with only a few disks, a very long timeout might required. Though, I'm not sure if such device shouldn't ignore the SYNC_CACHE command at all. DDN storage recommends to set the host timeout one seconds less than the command timeout on the controller (70 to 90 seconds). I hope I will find some time on Thursday or Friday to improve the patch. Thanks, Bernd -- Bernd Schubert DataDirect Networks -- 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
