From owner-freebsd-stable@FreeBSD.ORG Thu Jul 26 06:05:39 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 470CE16A41A for ; Thu, 26 Jul 2007 06:05:39 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 943D213C45A for ; Thu, 26 Jul 2007 06:05:38 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 7C1571CC05D; Wed, 25 Jul 2007 23:05:38 -0700 (PDT) Date: Wed, 25 Jul 2007 23:05:38 -0700 From: Jeremy Chadwick To: Scott Long Message-ID: <20070726060538.GA70793@eos.sc1.parodius.com> Mail-Followup-To: Scott Long , Howard Goldstein , freebsd-stable@freebsd.org References: <46A4E8FA.6010403@queue.to> <46A7B3FB.7010504@queue.to> <46A7B7AF.6080308@samsco.org> <46A7BF8C.5020909@queue.to> <46A7F2C2.2090009@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46A7F2C2.2090009@samsco.org> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: Howard Goldstein , freebsd-stable@freebsd.org Subject: Re: [resolved, naively] Re: geom vs ich through ar device - benchmarks? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2007 06:05:39 -0000 On Wed, Jul 25, 2007 at 07:02:58PM -0600, Scott Long wrote: > You should be able to sustain at least 70MB/s on a single modern drive > with SATA-1 or SATA-2. If you're not getting that then something in the > driver or the application is getting in the way. Even with the, um, > "problems" that SiI controllers are famous for, you should be able to > sustain a decent data rate on a single drive. Informative thread! I decided to try the same exact test as the OP, though I do not use ar or gmirror, on 3 different filesystems on 3 different disks (2 of the 3 disks are the same model though). I thought posting the results might be benefitial to readers. Hardware (and shared interrupts): ohci0: mem 0xd3003000-0xd3003fff irq 21 at device 2.0 on pci0 atapci1: port 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xd800-0xd80f mem 0xd3002000-0xd3002fff irq 23 at device 7.0 on pci0 ata2: on atapci1 ata3: on atapci1 atapci2: port 0x9e0-0x9e7,0xbe0-0xbe3,0x960-0x967,0xb60-0xb63,0xc400-0xc40f mem 0xd3001000-0xd3001fff irq 21 at device 8.0 on pci0 ata4: on atapci2 ata5: on atapci2 Disks: ad4: 476940MB at ata2-master SATA300 ad8: 190782MB at ata4-master SATA150 ad10: 476940MB at ata5-master SATA300 Filesystems: /dev/ad4s1d 451G 50G 365G 12% /backup /dev/ad8s1g 122G 1.1G 111G 1% /home /dev/ad10s1d 451G 50G 365G 12% /storage Filesystem tunables (tunefs(8)): /backup and /storage use the following custom variables, while /home uses the defaults: tunefs: maximum blocks per file in a cylinder group: (-e) 8192 tunefs: average file size: (-f) 65536 tunefs: average number of files in a directory: (-s) 256 sysctl.conf tunables: # Increase VFS read-ahead from 8 to 16. Slight performance increase. vfs.read_max=16 Results: [root@icarus ~]# dd if=/dev/zero of=/backup/ddtest bs=1m count=1000 1048576000 bytes transferred in 16.249101 secs (64531324 bytes/sec) [root@icarus ~]# dd if=/dev/zero of=/home/ddtest bs=1m count=1000 1048576000 bytes transferred in 23.940996 secs (43798345 bytes/sec) [root@icarus ~]# dd if=/dev/zero of=/storage/ddtest bs=1m count=1000 1048576000 bytes transferred in 14.729852 secs (71187137 bytes/sec) I tried changing the tunefs variables on /home (to match the other two filesystems on other disks), but the I/O rate did not change. A simple chart documenting the difference between the drives in the above tests likely explains the I/O speed difference: ad4: WD5000AAKS -- 7200rpm, 8.9ms seek, SATA300, 16MB cache ad8: WD2000JD -- 7200rpm, 8.9ms seek, SATA150, 8MB cache ad10: WD5000AAKS -- 7200rpm, 8.9ms seek, SATA300, 16MB cache The WD2000JD is a 1st-gen Caviar SE drive, which means it does not have a SATA300-capable controller. It does not have the OPT1 jumper either, which limits a SATA300 drive to SATA150. There's no way SATA300 provides a 40% speed gain over SATA150, so the obvious answer becomes the cache. One should also keep in mind that drive firmware revisions can also impact performance (StorageReview has proven this many times), but I don't have drives of different firmware revisions, so I can't compare that. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |