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 ? Thanks, Kashyap -- 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
