From owner-freebsd-current@FreeBSD.ORG Sat Jul 30 22:31:45 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1FC4616A420 for ; Sat, 30 Jul 2005 22:31:45 +0000 (GMT) (envelope-from julian@elischer.org) Received: from delight.idiom.com (delight.idiom.com [216.240.32.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F4B143D46 for ; Sat, 30 Jul 2005 22:31:44 +0000 (GMT) (envelope-from julian@elischer.org) Received: from idiom.com (idiom.com [216.240.32.1]) by delight.idiom.com (Postfix) with ESMTP id C37F12091AD; Sat, 30 Jul 2005 15:31:43 -0700 (PDT) Received: from [192.168.2.3] (home.elischer.org [216.240.48.38]) by idiom.com (8.12.11/8.12.11) with ESMTP id j6UMVhTO077043; Sat, 30 Jul 2005 15:31:43 -0700 (PDT) (envelope-from julian@elischer.org) Message-ID: <42EBFFCC.5010603@elischer.org> Date: Sat, 30 Jul 2005 15:31:40 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.7) Gecko/20050424 X-Accept-Language: en, hu MIME-Version: 1.0 To: Poul-Henning Kamp References: <5502.1122754726@phk.freebsd.dk> In-Reply-To: <5502.1122754726@phk.freebsd.dk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , Brian Candler Subject: Re: Apparent strange disk behaviour in 6.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2005 22:31:45 -0000 Poul-Henning Kamp wrote: > In message <42EBD958.6040402@elischer.org>, Julian Elischer writes: > > >>>If you know your queue-theory, you also know why busy% is >>>a pointless measurement: It represents the amount of time >>>where the queue is non-empty. It doesn't say anything about >>>how quickly the queue drains or fills. >> >>exactly.. I'm trying to work out why teh read and write queues are empty for so >>much time in a transaction that SHOULD be disk bound.... > > > I am very confident that the disk statistics collected in GEOM don't lie: > your disks are idle because nobody submits I/O requests. > > Look at your scheduler... I plan on doing just that.. I didn't say it was a problem in geom.. I just said that it is worth investigating why there is no cannel saturation when in theory that should be teh bottleneck. I have noticed this before.. 5 & 6 sometimes just don't seem to be "trying". they often have idle time when I would expect none.