To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freebsd.org/mailman/listinfo/freebsd-scsi
or, via email, send a message with subject or body 'help' to
freebsd-sc...@freebsd.org
You can reach the person managing the list at
freebsd-s...@freebsd.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-scsi digest..."
Today's Topics:
1. Re: adding a "retry command after a delay" error (Matthew Jacob)
----------------------------------------------------------------------
Message: 1
Date: Mon, 05 Apr 2010 13:34:52 -0700
From: Matthew Jacob <m...@feral.com>
Subject: Re: adding a "retry command after a delay" error
To: freebs...@freebsd.org
Message-ID: <4BBA496C...@feral.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 04/04/2010 11:37 PM, Alexander Motin wrote:
> Matthew Jacob wrote:
>
>> This is something I whipped up for dealing with some
>> active/active-after-failover-time systems. I wanted to have a general
>> facility to say of an ASC/ASCQ- retry the command, but after a period of
>> delay.
>>
>> Wonder if anyone had comments?
>> http://people.freebsd.org/~mjacob/delay_diffs.txt
>>
> I am not SCSI expert yet, but it seems OK for me. But I see two related
> questions there: delay time and number of retries allowed.
>
> Most of peripheral drivers now AFAIR ask to do only few (2-5) retries,
> so if delay will be short - it may give up too early, but long delay
> will probably reduce performance.
>
>
I've been doing some rethinking about this. It really is the devq that I
want to have stopped and retried with a timeout- not the entire sim.
Your point about periph drivers is well taken, and I thought about just
capturing this one in da, but it turns out that both sg && pass have the
same issue, hence the notion of generalizing it.
The sim change is working for the Panasas guys right now, but that's
just a bandaid. I'll think some more about this one.
Thanks for the comments!
------------------------------
End of freebsd-scsi Digest, Vol 363, Issue 2
********************************************