That will not help if the command is "SYNCHRONIZE_CACHE", as that ignores device settings, but uses scsi default timeout (30s), which is far too small for SATA based raid units. Scsi maintainers ignored that and a couple of other patches I wrote to improve error handling with Infortrend units. Will send the patches again soon. Also, if the abort command succeeds, it the command should be re-queued and should not result in an error. I think my patches also would increase verbosity to point ...

There is actually not much to test, as the patches had been the only solution to stabilize a large Lustre environment with dozens of Infortrend Raids. I spent months to debug Infortrend Raids, scsi stack and the LSI MPT fusion driver. Nowadays some patches are also used for DDN customers. I'm just always out of time to forward port it to more recent linux-git and to resend. Cheers, Bernd --

Will do. This will take some time though as I destroyed the fs by writing directly to the device, so I had to recreate it and start from scratch. I'm currently filling the new fs using a 60s device timeout as I'll try to reproduce the problem using different timeout values and the ext4 options you suggest. If I can find a reliable reproducer, I'll run blktrace and post the results. Regards Andre -- The only person who always got his work done by Friday was Robinson Crusoe

Hi I have implemented alloc_on_commit for EXT4. I haven't tested it thoroughly, but I could run some test scripts and postmark without any errors. Though it's working, the performance it very poor. As it was predicted by Ted, I guess it is because of the increased time in stalling of filesystem operations as block allocation is done while transaction is in LOCKED mode. I am sending the patch(for kernel 2.6.32.4) for my implementation. Please go through the patch and let me know if I am ...