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>