From owner-freebsd-arch Tue Nov 9 22: 9: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 A186A14EFC for ; Tue, 9 Nov 1999 22:09: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 HAA02829 for ; Wed, 10 Nov 1999 07:09:28 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id HAA05301 for freebsd-arch@freebsd.org; Wed, 10 Nov 1999 07:09:28 +0100 (MET) Received: from nomis.simon-shapiro.org (nomis.simon-shapiro.org [209.86.126.163]) by hub.freebsd.org (Postfix) with SMTP id 16E4614EFC for ; Tue, 9 Nov 1999 22:09:21 -0800 (PST) (envelope-from shimon@simon-shapiro.org) Received: (qmail 54860 invoked from network); 10 Nov 1999 06:09:08 -0000 Received: from localhost.simon-shapiro.org (HELO simon-shapiro.org) (127.0.0.1) by localhost.simon-shapiro.org with SMTP; 10 Nov 1999 06:09:08 -0000 Message-ID: <38290C04.8FC73862@simon-shapiro.org> Date: Wed, 10 Nov 1999 01:09:08 -0500 From: Simon Shapiro Organization: Simon's Garage X-Mailer: Mozilla 4.6 [en] (X11; I; FreeBSD 3.3-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Bruce Evans Cc: freebsd-arch@freebsd.org Subject: Re: I/O Evaluation Questions (Long but interesting!) References: Content-Type: text/plain; charset= Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Bruce Evans wrote: > > > > 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. Nope. I am getting 167MB/Sec for random block device. We are almost nine times faster on random WRITE (and I am comparing RAW I/O here to buffered there), twice as fast on random READ (again our RAW vs. their buffered. If you compare our block perfromance to theirs, we are almost fourty times faster. We are on-par on sequential WRITEs; we get 10MB/Sec RAW and 14 block, they report under 20. There must be some nasty trick to their sequential READ; It is 5 times as fast as their sequential WRITE. BTW, I may have stepped on a hornet nest here; panic: getnewbuf: inconsistent EMPTY queue, qindex=2 Another Question to this honorable forum: Other than heavy, multiple process, concurrent sequential and random I/O to the block and raw devices, what good way is there to verify that the OSM is working correctly? Making a filesystem is always successful, and after a panic, it fsck's perfectly, and the panic appears to be in other filesystems. > Bruce -- Sincerely Yours, Shimon@Simon-Shapiro.ORG 404.664.6401 Simon Shapiro Unwritten code has no bugs and executes at twice the speed of mouth To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message