From owner-cvs-src@FreeBSD.ORG Wed Feb 28 10:47:05 2007 Return-Path: X-Original-To: cvs-src@freebsd.org Delivered-To: cvs-src@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 034DD16A403; Wed, 28 Feb 2007 10:47:05 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id B7C7A13C4A8; Wed, 28 Feb 2007 10:47:04 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id BF59B170DC; Wed, 28 Feb 2007 10:47:02 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.8/8.13.8) with ESMTP id l1SAl2UN043717; Wed, 28 Feb 2007 10:47:02 GMT (envelope-from phk@critter.freebsd.dk) To: "M. Warner Losh" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 28 Feb 2007 03:30:55 MST." <20070228.033055.-135505832.imp@bsdimp.com> Date: Wed, 28 Feb 2007 10:47:02 +0000 Message-ID: <43716.1172659622@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/dev/usb umass.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2007 10:47:05 -0000 In message <20070228.033055.-135505832.imp@bsdimp.com>, "M. Warner Losh" writes : >Others have observed that the number of sectors on a disk should be >even. Therefore if maxsectors returned is even, it implies an odd >number of sectors and should be adjusted. Hmm, although generally true for present day disks, I don't think it is universal enough that I would want to rely solely on it. >number of sectors and should be adjusted. That might be an even >easier path to follow... I'm never sure when one can schedule >additional I/O inside of cam... Neither am I. Thinking about it, geom_disk might be a better place for it anyway. That way we could postpone announcment of the disk to GEOM tasting until we know it can actually answer a request. Spin-up and other long delays will not affect the system nearly as hard as they can today. Early on I thought about a mandatory "read first & last sector" check for all providers created in geom, but dropped it due to the excessive shake, rattle and roll of big diskfarms and complex layouts. But it might be a good idea to add it in a reduced form applied to all providers which come in at rank==1 (that way we would not do it for partitions, slices, mirrors etc). -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.