Michael Reed wrote: ...snip... >>>> - fast_io_fail_tmo and LLD callback: >>> >>> at (b): Minimally, we should terminate all active i/o requests marked >>> as type REQ_FASTFAIL. From an api perspective, driver support >>> for this is optional. And we must also assume that there will >>> be implementations which have to abort all i/o in order to >>> terminate those marked REQ_FASTFAIL. Is this acceptable ? >>> (it meets the "always" condition above) >>> >>> Q: so far we've limited the io to those w/ REQ_FASTFAIL. >>> Would we ever want to allow a user to fast fail all i/o >>> regardless of the request flags ? (in case they flags >>> weren't getting set on all the i/o the user wanted to >>> see fail ?) >> REQ_FAILFAST appears to influence retries during error recovery so >> there may be unexpected side effects of doing this. But, that said, >> I'd say yes. From my perspective, I'd make this the default behavior. >> >> In talking with our volume manager people, the question raised was >> "Why would you want some i/o to fail quickly and some not?" >> They even considered non-i/o scsi commands. >> ...snip... > In thinking about this over night, I would like to withdraw my previous comments. (Hence the snip!) Let's take the case of real time capture from a device and post processing of that data. The capture operation would likely want a fast fail to avoid dropping data. The post processing of that data would like to wait for the device to return to avoid disruption and potential premature termination of the job. Under the above scenario, assuming it's a valid scenario, are there mechanisms in place to allow an application to tag an i/o stream for fast fail? Mike - : 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
