From owner-freebsd-questions@FreeBSD.ORG Sat Mar 3 07:14:25 2007 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 68B1E16A403; Sat, 3 Mar 2007 07:14:25 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1-3.pacific.net.au [61.8.2.210]) by mx1.freebsd.org (Postfix) with ESMTP id 248FD13C467; Sat, 3 Mar 2007 07:14:25 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout1.pacific.net.au (Postfix) with ESMTP id 792D33280D8; Sat, 3 Mar 2007 18:14:23 +1100 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (Postfix) with ESMTP id 4350F8C09; Sat, 3 Mar 2007 18:14:22 +1100 (EST) Date: Sat, 3 Mar 2007 18:14:15 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Brooks Davis In-Reply-To: <20070302152832.GA79187@lor.one-eyed-alien.net> Message-ID: <20070303174120.F13432@delplex.bde.org> References: <45E7F09B.7070005@zedat.fu-berlin.de> <20070302152832.GA79187@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-performance@freebsd.org, "O. Hartmann" , freebsd-questions@freebsd.org Subject: Re: (S)ATA performance in FBSD 6.2/7.0 X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2007 07:14:25 -0000 On Fri, 2 Mar 2007, Brooks Davis wrote: > Also, you should time the actual copy and do the math to verify that > vmstat is actually producing valid results. It's possible there's a bug > in vmstat or the underlying statistics it uses. There is certainly a bug in the underlying statistics. For ATA disks, at least with the ata driver, the maximum transfer size in DMA mode is 64K, so any reports of a block size of 128K for SATA disks are wrong. The block size of 128K reported by vmstat is actually a virtual size. For most or types of disks, the GEOM layer virtualizes the physical maximum size MAXPHYS = 128K so that layers above GEOM including statistics gathering and file systems cannot see the physical size. For writing large files, this normally confuses ffs and vfs clustering into producing contiguous writes of 128K. This is good for efficiency, but it is not what the hardware sees or what you want for statistics. The contiguous writes of 128K get split up into 2 sequential writes of 64K. However, 64K is more than large enough for efficiency, so the bug in the underlying statistics doesn't matter, at least if vmstat reports only 128K blocks. If it reported 64K-blocks then you would have to worry about the contiguous block sizes being a mixture of 128K and much smaller blocks, with the much smaller blocks (actually, more the seeks across gaps to get to the smaller blocks) being very inefficient. Bruce