Subject: Re: scsipi changes
To: None <email@example.com>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 07/16/2001 11:41:04
In message <20010716092924.O96667firstname.lastname@example.org>,
Matthew Jacob writes:
>>> It's perhaps best in this case to let the target device driver decide, based
>>> on policy, whether it wants to wait for a period before it begins to start
>>> failing commands and then up to the caller's cleverness as to what it would
>>> like to do (detach, retry, fallback to alternate volumes, etc.).
>> Hum, I think this should be in the core scsipi itself, not in upper
>> level drivers. It's better to have a consistent behavior for all devices.
>Oh, I suppose. I guess that because the target driver can reject a detach,
>then you can your shorts wrapped your ankles when that happen.
>Still, it's the target driver who really should be deciding how important a
>selection timeout is.
Yeah, but idiosyncratic per-driver timeouts with no or idiosyncratic
ways to change them leads to chaos.
Here's a strawman: keep timeout information in one consistent place in
the mid-layer, with
1) A global default
2) A callback for any hba instance to override the default for itself
(Matt's "policy"), and a config-time message letting the user know
the HBA asserted its "policy".
3) A way to force wired-down defaults in a wired-down kernel config
I'm thinking iSCSI...