On 04/19/2010 06:32 AM, Desai, Kashyap wrote:
I am facing one issue with scsi stack. Here is a background of my test. Mount ext3 file system with journaling support with barrier=1, commit=5 Now, with this setup file system will do submit_bh with WRITE_BARRIER flag set for interval of 5 seconds. (This is a part of journaling.) Eventually it will call queue_flush() which will generate SCSI command of CDB: SYNCHRONIZE_CAHCE and insert it into the request queue. I observed that creation of SYNCHRONIZE_CACHE is a part of sd_prepare_flush(). Here we have timeout set to SD_TIMEOUT but retries are not set. Because of retries of the request is not set, there is no retries allowed for SYNCHRONIZE_CACHE at mid layer. Because of zero retries for SYNCHRONIZE_CACHE command at mid-layer, it is creating trouble for file system. In current situation, Even though LLD send back commands with DID_RESET, SYNCHRONIZE_CACHE will fail immediately without going for any retries, when HBA is in recovery state. Eventually this information goes to File system and it sees SYNCHRONIZE_CAHCE is failed and file system goes to Read only mode. My question is "Can we add in sd_prepare_flush(), rq->retries = X" some reasonable retries value ?
I am not sure where we want it, but I think we want to be able to set both the retries and timeout. I have seen where a sync cache can take longer than the default 30 secs.
Do you think we want to the block layer to manage retries/timeouts for 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/ ?
-- 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
