Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 29 Mar 2005 10:59:32 -0800
From:      Drew Tomlinson <drew@mykitchentable.net>
To:        Bob Johnson <bob89@bobj.org>
Cc:        freebsd-questions@freebsd.org
Subject:   Re: sbp, camcontrol, and Tagged Queuing
Message-ID:  <4249A594.6000606@mykitchentable.net>
In-Reply-To: <200503172323.27821.bob89@bobj.org>
References:  <423A4647.5000709@mykitchentable.net> <200503172323.27821.bob89@bobj.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 3/17/2005 8:23 PM Bob Johnson wrote:

>On Thursday 17 March 2005 10:08 pm, Drew Tomlinson wrote:
>  
>
>>I posted this a while back and am still having the same problem.  Can
>>anyone offer any insight as to if the sbp man page suggestion about tagged
>>queuing is something I should try?  Is there any risk of screwing up my
>>drives by trying this?
>>
>Tagged queueing queues up multiple instructions for the drive simultaneously.  
>The drive then attempts to sort them out and execute them in optimum order. 
>Some drives that claim to support tagged queueing do not correctly do so, and 
>don't perform well when it is used (and may lose data).  If you set the queue 
>size to one, as recommended in the passage you reference, then only one 
>instruction will be issued to the drive at time, and it will behave like a 
>drive without tagged queueing.  It will do no harm to the drive.  If the 
>drive correctly implements tagged queueing, this will slow down the drive, 
>but if it does not correctly implement it, then this may dramatically speed 
>up the drive (and make it more stable).  I have an external drive that 
>manages 1.3 MBps transfers with queueing enabled, and 25 MBps transfers when 
>I set the queue size to one.
>
>As for whether it will help your specific problem, I don't know, but I can't 
>see how it would do any harm to test it.
>  
>
Using the camcontrol utility, I found these drives were already set to "1"

blacklamb# camcontrol tags da2 -v
(pass3:sbp0:0:0:0): dev_openings  1
(pass3:sbp0:0:0:0): dev_active    0
(pass3:sbp0:0:0:0): devq_openings 1
(pass3:sbp0:0:0:0): devq_queued   0
(pass3:sbp0:0:0:0): held          0
(pass3:sbp0:0:0:0): mintags       2
(pass3:sbp0:0:0:0): maxtags       255

blacklamb# camcontrol tags da3 -v
(pass4:sbp0:0:0:1): dev_openings  1
(pass4:sbp0:0:0:1): dev_active    0
(pass4:sbp0:0:0:1): devq_openings 1
(pass4:sbp0:0:0:1): devq_queued   0
(pass4:sbp0:0:0:1): held          0
(pass4:sbp0:0:0:1): mintags       2
(pass4:sbp0:0:0:1): maxtags       255

Thus setting tagged queuing to "1" had no effect.  Thanks again for your 
explanation.  I sure wish I could solve this issue!

Thanks,

Drew

>This issue is not specific to FreeBSD.  Any OS that supports tagged queuing 
>has problems with some drives.
>
>- Bob
>
>[...]
>
>  
>
>>da2 and da3 are two IDE drives in a firewire enclosure.  These are also
>>the drives that come up "referenced" after restarting.  What do these
>>errors mean?  How can I correct them?  Is the following section from the
>>sbp man page applicable to my situation?
>>
>>Some (broken) HDDs don't work well with tagged queuing. If you have prob-
>>lems with such drives, try ``camcontrol [device id] tags -N 1'' to dis-
>>able tagged queuing.
>>
>>Thanks for your help!
>>
>>Drew
>>
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4249A594.6000606>