From owner-freebsd-stable@FreeBSD.ORG Sat May 14 10:29:13 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A95D16A4CE; Sat, 14 May 2005 10:29:13 +0000 (GMT) Received: from mail.helenmarks.co.uk (mail.helenmarks.co.uk [82.68.196.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9D9143D41; Sat, 14 May 2005 10:29:11 +0000 (GMT) (envelope-from dom@goodforbusiness.co.uk) Received: from localhost (localhost [127.0.0.1]) by mail.helenmarks.co.uk (Postfix) with ESMTP id 35418222403; Sat, 14 May 2005 11:29:08 +0100 (BST) Received: from mail.helenmarks.co.uk ([127.0.0.1]) by localhost (mail.helenmarks.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41511-07; Sat, 14 May 2005 11:29:01 +0100 (BST) Received: from egg.helenmarks.co.uk (egg.helenmarks.co.uk [192.168.15.3]) by mail.helenmarks.co.uk (Postfix) with ESMTP id EEFD0222402; Sat, 14 May 2005 11:29:00 +0100 (BST) From: Dominic Marks Organization: GoodforBusiness.co.uk To: freebsd-stable@freebsd.org Date: Sat, 14 May 2005 11:30:01 +0100 User-Agent: KMail/1.8 References: <20050514093217.C6088E082A@oak.tantieme.ru> In-Reply-To: <20050514093217.C6088E082A@oak.tantieme.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505141130.01541.dom@goodforbusiness.co.uk> X-Virus-Scanned: By ClamAV 0.80 cc: vohand@gmail.com cc: pjd@FreeBSD.org Subject: Re: gmirror X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 May 2005 10:29:13 -0000 On Saturday 14 May 2005 10:22, vohand@gmail.com wrote: > Hardware: SATA RAID adapter with SiliconImage 3114 chip. 2 SATA HDD. > I did gmirror. > a) This is gmirror feature ? > b) This is hardware feature (SiliconImage 3114 chip) ? I don't think is related to your hardware. I have a Dell PowerEdge SC1425 which is exhibiting the same behaviour from gmirror, my disc controller is an onboard Intel ICH5. System: FreeBSD 5.4-STABLE @ Sun Apr 10 14:07:46 UTC 2005 atapci1: port 0xccc0-0xcccf,0xccd8-0xccdb, 0xcce0-0xcce7,0xccf0-0xccf3,0xccf8-0xccff irq 18 at device 31.2 on pci0 ata2: channel #0 on atapci1 ata3: channel #1 on atapci1 mail# dmesg | grep ad4 ad4: 76293MB [155009/16/63] at ata2-master SATA150 mail# diskinfo -t ad4 Seek times: Full stroke: 250 iter in 5.606627 sec = 22.427 msec Half stroke: 250 iter in 4.382610 sec = 17.530 msec Quarter stroke: 500 iter in 6.969860 sec = 13.940 msec Short forward: 400 iter in 1.940076 sec = 4.850 msec Short backward: 400 iter in 2.349238 sec = 5.873 msec Seq outer: 2048 iter in 0.228509 sec = 0.112 msec Seq inner: 2048 iter in 0.237599 sec = 0.116 msec Transfer rates: outside: 102400 kbytes in 1.755089 sec = 58345 kbytes/sec middle: 102400 kbytes in 2.106003 sec = 48623 kbytes/sec inside: 102400 kbytes in 3.496732 sec = 29284 kbytes/sec Pretty reasonable results. mail# dmesg | grep ad6 ad6: 76319MB [155061/16/63] at ata3-master SATA150 The second drive achieves slightly better seeking, but lower throughput. But the variation between ad4 and ad6 is very small as I would expect for two virtually identical drives. mail# diskinfo -t ad6 Seek times: Full stroke: 250 iter in 4.936300 sec = 19.745 msec Half stroke: 250 iter in 3.675749 sec = 14.703 msec Quarter stroke: 500 iter in 5.970199 sec = 11.940 msec Short forward: 400 iter in 1.937453 sec = 4.844 msec Short backward: 400 iter in 2.347955 sec = 5.870 msec Seq outer: 2048 iter in 0.211831 sec = 0.103 msec Seq inner: 2048 iter in 0.218748 sec = 0.107 msec Transfer rates: outside: 102400 kbytes in 1.754634 sec = 58360 kbytes/sec middle: 102400 kbytes in 2.107054 sec = 48599 kbytes/sec inside: 102400 kbytes in 3.522545 sec = 29070 kbytes/sec Now the same test against the gmirror: mail# diskinfo -t /dev/mirror/gmirror0 Seek times: Full stroke: 250 iter in 1.347611 sec = 5.390 msec Half stroke: 250 iter in 1.335664 sec = 5.343 msec Quarter stroke: 500 iter in 2.653382 sec = 5.307 msec Short forward: 400 iter in 2.254421 sec = 5.636 msec Short backward: 400 iter in 2.057330 sec = 5.143 msec Seq outer: 2048 iter in 0.265052 sec = 0.129 msec Seq inner: 2048 iter in 0.274519 sec = 0.134 msec Transfer rates: outside: 102400 kbytes in 2.774400 sec = 36909 kbytes/sec middle: 102400 kbytes in 3.138420 sec = 32628 kbytes/sec inside: 102400 kbytes in 4.498140 sec = 22765 kbytes/sec The seek times are way down, which is great, and makes sense using a round-robin strategy on the mirror, but my peak transfer rate has been almost halved too. I don't mind this too much as in my application low seek times are worth more than high transfer rates, but it is still puzzling to me to see such a remarkable drop in throughput. Thanks very much for insight, -- Dominic GoodforBusiness.co.uk I.T. Services for SMEs in the UK.