Date: Fri, 1 Nov 2002 21:07:44 -0800 (PST) From: Nate Lawson <nate@root.org> To: ANYBODY <somebody@kashmir.etowns.net> Cc: scsi@freebsd.org Subject: Re: adaptec ahc : seagate da : current Message-ID: <Pine.BSF.4.21.0211012104200.98454-100000@root.org> In-Reply-To: <20021102042626.GA739@hurd1.kashmir.etowns.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 1 Nov 2002, ANYBODY wrote: > On Fri, Nov 01, 2002 at 04:38:06PM -0800, ANYBODY wrote: > > On Fri, Nov 01, 2002 at 12:11:08PM -0800, Nate Lawson wrote: > > > Have you done what he said? man 8 camcontrol (see the "tags" subcommand). > > > > > > -Nate > > > > > > > Sorry dont know how but missed it. thank you for reminding. > > here is what I got: > > # camcontrol tags da0 -v > > (pass0:ahc0:0:3:0): dev_openings 63 > > (pass0:ahc0:0:3:0): dev_active 0 > > (pass0:ahc0:0:3:0): devq_openings 63 > > (pass0:ahc0:0:3:0): devq_queued 0 > > (pass0:ahc0:0:3:0): held 0 > > (pass0:ahc0:0:3:0): mintags 2 > > (pass0:ahc0:0:3:0): maxtags 255 > > > > ---- > > looks like i can set the dev_openings & devq_openings > > to anywhere between 2 and 255, with it being 63 now. > > I have no idea as to what, if at all would be a better > > number. any suggestions? > > Question does the kernel change these values dynamically > > perhaps as a result of the errors like the ones I am getting? > > If not howcome the problem occurs only if there is a little > > over moderate disk activity within probably a short while > > after bootup, and inspite of howmuch activity occurs later > > this problem most rarely occurs again. > > thanks and appreciate your help > > Saurabh Gupta > > > > Answering my own question : > these values are indeed dynamic in a running system. > the cam driver or the kernel keeps negotiating! > @least thats what I found after picking the numbers > every few seconds for an hour. > during bootup my numbers were 255 for the dev*openings > and that is when the drive gets into trouble. > If the activity is mild in the begining(bootup) the > stable dev*opening values are probably negotiated down > smoothly in a little while......and when the > understanding of a stable number is low enough the > drive doesnt get stuck anymore. > I guess I should go read the camcontrol driver in > detail before sounding off my opinion anymore > or risk being one of the BLIND men trying to FEEL an > elephant! Yes, the values are dynamically backed off as necessary. To avoid the timeout, set the maxtags lower via adding the appropriate camcontrol to rc.local. You can get a good idea on the lower bound for your drive by what it is dynamically resized to. FYI, even a tag depth of 8 allows for significant concurrency. But do some performance testing to see what works for you. -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0211012104200.98454-100000>