From owner-cvs-src@FreeBSD.ORG Tue Oct 7 11:45:33 2003 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2F0DE16A4B3; Tue, 7 Oct 2003 11:45:33 -0700 (PDT) Received: from list.adaptec.com (list.adaptec.com [216.52.22.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id C08C443F93; Tue, 7 Oct 2003 11:45:31 -0700 (PDT) (envelope-from gibbs@scsiguy.com) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by list.adaptec.com (8.12.8/8.12.8) with ESMTP id h97IjU3d030574; Tue, 7 Oct 2003 11:45:30 -0700 Received: from [10.100.253.70] (aslan.btc.adaptec.com [10.100.253.70]) by redfish.adaptec.com (8.8.8p2+Sun/8.8.8) with ESMTP id LAA14326; Tue, 7 Oct 2003 11:45:24 -0700 (PDT) Date: Tue, 07 Oct 2003 12:49:00 -0600 From: "Justin T. Gibbs" To: Poul-Henning Kamp , Nate Lawson Message-ID: <44570000.1065552539@aslan.btc.adaptec.com> In-Reply-To: <22886.1065458527@critter.freebsd.dk> References: <22886.1065458527@critter.freebsd.dk> X-Mailer: Mulberry/3.1.0b8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/cam/scsi scsi_cd.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Justin T. Gibbs" List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2003 18:45:33 -0000 > In message <20031006093515.S3158@root.org>, Nate Lawson writes: > >> Shouldn't the following read capacity command be able to detect the loss >> of a drive as well? > > The trick here is the low timeout. No. The trick is removing any retries so that retriable errors are ignored. The "problem" never was the timeout value, but the drive returning "in the process of becoming ready" status that triggered error recovery to wait for the device. GEOM shouldn't be waiting around for devices unless they are accessed or have the potential to be accessed (devfs lookup that fails to match an already probed entry) which would avoid this delay even with the original, correct error recovery. >> Did kdm@ review this? > If he had, it would have said so in the commit message. If he had, I'm sure he would have rejected the change. -- Justin