From owner-freebsd-arch Tue Nov 9 21:39:31 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id D449814DE5 for ; Tue, 9 Nov 1999 21:39:29 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id GAA02646 for ; Wed, 10 Nov 1999 06:39:23 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id GAA05228 for freebsd-arch@freebsd.org; Wed, 10 Nov 1999 06:39:23 +0100 (MET) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 75A6B14DE5 for ; Tue, 9 Nov 1999 21:39:10 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from p13-ts5.syd2.zeta.org.au (beefcake.zeta.org.au [203.26.10.12]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id QAA30776; Wed, 10 Nov 1999 16:44:52 +1100 Date: Wed, 10 Nov 1999 16:38:51 +1100 (EST) From: Bruce Evans X-Sender: bde@alphplex.bde.org To: Simon Shapiro Cc: freebsd-arch@freebsd.org Subject: Re: I/O Evaluation Questions (Long but interesting!) In-Reply-To: <3828F322.B62D174E@simon-shapiro.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Block devices have to use a fixed block size. This size is > > normally BLKDEV_IOSIZE. For historical reasons, BLKDEV_IOSIZE > What I observed, is that ALL block device I/O is happening > in 8KB calls, except for the 512 bytes calls for slice > and partition management (5 of them, methinks). 8KB is probably for a filesystem-related block size being used instead of BLKDEV_IOSIZE. This happens when the device is a partition on a labeled drive and the label entry says that the partition type is 4.2BSD and the block size is 8192. > The 10:1 random write problem may be mine; An ancient > and well hidden bug in st.d which made lock unlock calls > for every i/o. Drivers can have this bug too :-). The wd driver has it :-(. In RELENG_3, the specfs i/o routines check the label for every block, although this is worse than useless. Checking the label involves calling the driver ioctl routine, and wdioctl() does careful locking for all ioctls although it doesn't need to for most. wd's locking involves waiting until the controller is inactive and this has bad effects on the throughput. > We run circles around NT in the Random I/O department, > but take a beating in the sequential I/O arena; > For about the same hardware, they do 98 MB/Sec, > I cannot get more than 45. I've always though FreeBSD has the opposite problem. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message