freebsd-scsi Digest, Vol 360, Issue 3
freebsd-sc...@freebsd.org
freebs...@freebsd.org
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: freebsd-scsi Digest, Vol 360, Issue 2 (Tom_...@Dell.com)
2. Optimum dev_openings value (Glen Barber)
3. Re: Optimum dev_openings value (Matthew Jacob)
----------------------------------------------------------------------
Message: 1
Date: Thu, 18 Mar 2010 09:55:37 -0500
From: <Tom_...@Dell.com>
Subject: RE: freebsd-scsi Digest, Vol 360, Issue 2
To: <freebs...@freebsd.org>
Message-ID:
<2F96965A484FC042AA2B...@ausx3mpc127.aus.amer.dell.com>
Content-Type: text/plain; charset="us-ascii"
Un fucking subscribe
Unsubscribe
Fucking unsubscribe
-----Original Message-----
From: owner-fre...@freebsd.org
[mailto:owner-fre...@freebsd.org] On Behalf Of
freebsd-sc...@freebsd.org
Sent: Thursday, March 18, 2010 5:00 AM
To: freebs...@freebsd.org
Subject: freebsd-scsi Digest, Vol 360, Issue 2
Send freebsd-scsi mailing list submissions to
freebs...@freebsd.org
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: pass(4): always retry CAM_REQUEUE_REQ ccbs (Kenneth D. Merry)
2. Re: pass(4): always retry CAM_REQUEUE_REQ ccbs (Andriy Gapon)
3. problems with mfi/DELL Perc6? (Daniel Braniss)
----------------------------------------------------------------------
Message: 1
Date: Wed, 17 Mar 2010 11:28:47 -0600
From: "Kenneth D. Merry" <k...@kdm.org>
Subject: Re: pass(4): always retry CAM_REQUEUE_REQ ccbs
To: Andriy Gapon <a...@icyb.net.ua>
Cc: freebs...@freebsd.org
Message-ID: <20100317172...@nargothrond.kdm.org>
Content-Type: text/plain; charset=us-ascii
On Wed, Mar 10, 2010 at 13:24:37 +0200, Andriy Gapon wrote:
>
> At present pass(4) never retries a request (or performs any other kind
of error
> recovery) unless the request has CAM_PASS_ERR_RECOVER flag set.
> This gives applications a control over error checking and handling.
> But I think that in the case of CAM_REQUEUE_REQ status error recovery,
> specifically a request retry, should always be performed.
>
> Rationale:
> CAM_REQUEUE_REQ is really an internal flag/state in CAM subsystem.
> It doesn't convey any information about state of medium, device, bus,
controller
> or the ccb itself. Application can not make any meaningful
differentiation
> based on this status. It either should always retry a ccb with this
status or
> face truly random failures. As such, I haven't encountered so far any
> application that expects to get CAM_REQUEUE_REQ status.
> So I think that CAM_REQUEUE_REQ should be contained within the CAM and
never be
> leaked to applications unless retry count is exhausted (to prevent
endless loops
> in case of programming errors, primarily).
>
> What do you think?
> Do you see any reason not to do it?
Is there a particular case you're running into where CAM_REQUEUE_REQ is
getting returned?
I think it's better to keep the model as-is, to avoid confusion. Either
the application is handling errors, and it can get any CAM status value,
or
it is asking the pass(4) driver to do error recovery and it doesn't have
to
handle things until error recovery is done and retries are exhausted.
If we've got a SIM driver that is returning CAM_REQUEUE_REQ when it
shouldn't, we should probably look at that. Retries can get used up for
various target-related reasons, like unit attention conditions, and we
don't want to use CAM_REQUEUE_REQ when it isn't really needed.
Ken
--
Kenneth Merry
k...@kdm.org
------------------------------
Message: 2
Date: Wed, 17 Mar 2010 20:00:13 +0200
From: Andriy Gapon <a...@icyb.net.ua>
Subject: Re: pass(4): always retry CAM_REQUEUE_REQ ccbs
To: "Kenneth D. Merry" <k...@kdm.org>
Cc: freebs...@freebsd.org
Message-ID: <4BA118AD...@icyb.net.ua>
Content-Type: text/plain; charset=ISO-8859-1
on 17/03/2010 19:28 Kenneth D. Merry said the following:
> On Wed, Mar 10, 2010 at 13:24:37 +0200, Andriy Gapon wrote:
>> At present pass(4) never retries a request (or performs any other
kind of error
>> recovery) unless the request has CAM_PASS_ERR_RECOVER flag set.
>> This gives applications a control over error checking and handling.
>> But I think that in the case of CAM_REQUEUE_REQ status error
recovery,
>> specifically a request retry, should always be performed.
>>
>> Rationale:
>> CAM_REQUEUE_REQ is really an internal flag/state in CAM subsystem.
>> It doesn't convey any information about state of medium, device, bus,
controller
>> or the ccb itself. Application can not make any meaningful
differentiation
>> based on this status. It either should always retry a ccb with this
status or
>> face truly random failures. As such, I haven't encountered so far
any
>> application that expects to get CAM_REQUEUE_REQ status.
>> So I think that CAM_REQUEUE_REQ should be contained within the CAM
and never be
>> leaked to applications unless retry count is exhausted (to prevent
endless loops
>> in case of programming errors, primarily).
>>
>> What do you think?
>> Do you see any reason not to do it?
>
> Is there a particular case you're running into where CAM_REQUEUE_REQ
is
> getting returned?
Yes, access to ATAPI devices with ahci(4).
> I think it's better to keep the model as-is, to avoid confusion.
Either
> the application is handling errors, and it can get any CAM status
value, or
> it is asking the pass(4) driver to do error recovery and it doesn't
have to
> handle things until error recovery is done and retries are exhausted.
I've had a chat with Justin Gibbs and he is of the same opinion. His
explanation
makes sense to me. I didn't look beyond 'for home use' applications
when I came
up with the suggestion.
So, I think that we'd better teach affected applications about
CAM_REQUEUE_REQ.
> If we've got a SIM driver that is returning CAM_REQUEUE_REQ when it
> shouldn't, we should probably look at that. Retries can get used up
for
> various target-related reasons, like unit attention conditions, and we
> don't want to use CAM_REQUEUE_REQ when it isn't really needed.
I guess that this would be ideal.
I think that it is an implementation detail in ahci(4) that some
commands may get
CAM_REQUEUE_REQ status. But I am not sure if there is an easy way to
fix that
given the general logic in that driver.
--
Andriy Gapon
------------------------------
Message: 3
Date: Thu, 18 Mar 2010 10:59:43 +0200
From: Daniel Braniss <da...@cs.huji.ac.il>
Subject: problems with mfi/DELL Perc6?
To: freebs...@freebsd.org
Message-ID: <E1NsBZv-...@kabab.cs.huji.ac.il>
Content-Type: text/plain; charset=us-ascii
hi,
we keep seeing these timeouts when there is heavy writes to the mfi:
...
mfi1: COMMAND 0xffffff80009cd0f0 TIMEOUT AFTER 6564 SECONDS
mfi1: COMMAND 0xffffff80009cd0f0 TIMEOUT AFTER 6594 SECONDS
mfi1: COMMAND 0xffffff80009cd0f0 TIMEOUT AFTER 6624 SECONDS
mfi1: COMMAND 0xffffff80009cd0f0 TIMEOUT AFTER 6654 SECONDS
mfi1: COMMAND 0xffffff80009cd0f0 TIMEOUT AFTER 6684 SECONDS
mfi1: COMMAND 0xffffff80009ce498 TIMEOUT AFTER 35 SECONDS
mfi1: COMMAND 0xffffff80009ce9e8 TIMEOUT AFTER 37 SECONDS
mfi1: COMMAND 0xffffff80009cec08 TIMEOUT AFTER 38 SECONDS
mfi1: COMMAND 0xffffff80009cc3a8 TIMEOUT AFTER 47 SECONDS
mfi1: COMMAND 0xffffff80009ceda0 TIMEOUT AFTER 31 SECONDS
mfi1: COMMAND 0xffffff80009ce9e8 TIMEOUT AFTER 46 SECONDS
mfi1: COMMAND 0xffffff80009cda80 TIMEOUT AFTER 55 SECONDS
...
mfi1: COMMAND 0xffffff80009cd0f0 TIMEOUT AFTER 6624 SECONDS
the card is:
mfi1: <Dell PERC 6> port 0xec00-0xecff mem
0xdf280000-0xdf2bffff,0xdf2c0000-0xd
f2fffff irq 38 at device 0.0 on pci6
mfi1: Megaraid SAS driver Ver 3.00
any idea what the message means?
thanks,
danny
------------------------------
End of freebsd-scsi Digest, Vol 360, Issue 2
********************************************
------------------------------
Message: 2
Date: Thu, 18 Mar 2010 11:41:38 -0400
From: Glen Barber <glen.j...@gmail.com>
Subject: Optimum dev_openings value
To: sc...@freebsd.org
Message-ID: <20100318154...@orion.hsd1.pa.comcast.net>
Content-Type: text/plain; charset=us-ascii
Hi,
I have three machines running 8.0-RELEASE, each with two mirrored Seagate
SCSI disks using ZFS. In making sure these machines are performing as
best as possible, I'm trying to find what the best practices are with
regards to dev_openings values, and what determines the default
dev_openings value.
Two machines have identical ahc(4) Adaptec AIC7899 Ultra160 SCSI adapters,
but display different defaults, which I have not had luck finding an
explanation:
h04# camcontrol tags da0 -v
(pass0:ahc1:0:0:0): dev_openings 33
(pass0:ahc1:0:0:0): dev_active 0
(pass0:ahc1:0:0:0): devq_openings 33
(pass0:ahc1:0:0:0): devq_queued 0
(pass0:ahc1:0:0:0): held 0
(pass0:ahc1:0:0:0): mintags 2
(pass0:ahc1:0:0:0): maxtags 255
h21# camcontrol tags da0 -v
(pass0:ahc0:0:0:0): dev_openings 64
(pass0:ahc0:0:0:0): dev_active 0
(pass0:ahc0:0:0:0): devq_openings 64
(pass0:ahc0:0:0:0): devq_queued 0
(pass0:ahc0:0:0:0): held 0
(pass0:ahc0:0:0:0): mintags 2
(pass0:ahc0:0:0:0): maxtags 255
h04# camcontrol devlist
<SEAGATE ST318406LC 0109> at scbus1 target 0 lun 0 (pass0,da0)
<SEAGATE ST318406LC 010A> at scbus1 target 1 lun 0 (pass1,da1)
h21# camcontrol devlist
<SEAGATE ST3146855LC 0003> at scbus0 target 0 lun 0 (pass0,da0)
<SEAGATE ST3146855LC 0003> at scbus0 target 1 lun 0 (pass1,da1)
Is there an obvious explanation for the difference here?
The third machine uses sym(4), which I expect would cause a different
default dev_openings (currently defaulted to 44).
Is there a general rule to adjusting this value?
--
Glen Barber
------------------------------
Message: 3
Date: Thu, 18 Mar 2010 10:06:00 -0700
From: Matthew Jacob <m...@feral.com>
Subject: Re: Optimum dev_openings value
To: freebs...@freebsd.org
Message-ID: <4BA25D78...@feral.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Openings changes reflect when and how a device sends back a QUEUE FULL
message, which causes FreeBSD to adjust the openings.
That is disk, access pattern, and timing dependent.
There are a number of theories about whether the 'openings' value should
be bumped back up after having been throttled down. Nobody can agree on
these theories, so the openings stay where they are. You might try
manually adjusting them up on a periodic basis.
> Hi,
>
> I have three machines running 8.0-RELEASE, each with two mirrored Seagate
> SCSI disks using ZFS. In making sure these machines are performing as
> best as possible, I'm trying to find what the best practices are with
> regards to dev_openings values, and what determines the default
> dev_openings value.
>
> Two machines have identical ahc(4) Adaptec AIC7899 Ultra160 SCSI adapters,
> but display different defaults, which I have not had luck finding an
> explanation:
>
> h04# camcontrol tags da0 -v
> (pass0:ahc1:0:0:0): dev_openings 33
> (pass0:ahc1:0:0:0): dev_active 0
> (pass0:ahc1:0:0:0): devq_openings 33
> (pass0:ahc1:0:0:0): devq_queued 0
> (pass0:ahc1:0:0:0): held 0
> (pass0:ahc1:0:0:0): mintags 2
> (pass0:ahc1:0:0:0): maxtags 255
>
> h21# camcontrol tags da0 -v
> (pass0:ahc0:0:0:0): dev_openings 64
> (pass0:ahc0:0:0:0): dev_active 0
> (pass0:ahc0:0:0:0): devq_openings 64
> (pass0:ahc0:0:0:0): devq_queued 0
> (pass0:ahc0:0:0:0): held 0
> (pass0:ahc0:0:0:0): mintags 2
> (pass0:ahc0:0:0:0): maxtags 255
>
> h04# camcontrol devlist
> <SEAGATE ST318406LC 0109> at scbus1 target 0 lun 0 (pass0,da0)
> <SEAGATE ST318406LC 010A> at scbus1 target 1 lun 0 (pass1,da1)
>
> h21# camcontrol devlist
> <SEAGATE ST3146855LC 0003> at scbus0 target 0 lun 0 (pass0,da0)
> <SEAGATE ST3146855LC 0003> at scbus0 target 1 lun 0 (pass1,da1)
>
> Is there an obvious explanation for the difference here?
>
> The third machine uses sym(4), which I expect would cause a different
> default dev_openings (currently defaulted to 44).
>
> Is there a general rule to adjusting this value?
>
>
------------------------------
End of freebsd-scsi Digest, Vol 360, Issue 3
********************************************