From owner-freebsd-amd64@FreeBSD.ORG Wed Oct 4 17:00:59 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 432D116A4AB for ; Wed, 4 Oct 2006 17:00:59 +0000 (UTC) (envelope-from chris@behanna.org) Received: from cassoulet.panasas.com (gw-e.panasas.com [65.194.124.178]) by mx1.FreeBSD.org (Postfix) with ESMTP id 861A043D62 for ; Wed, 4 Oct 2006 17:00:54 +0000 (GMT) (envelope-from chris@behanna.org) Received: from [172.17.3.236] (cassoulet.panasas.com [172.17.1.122]) by cassoulet.panasas.com (8.12.10/8.12.10) with ESMTP id k94H0paT020015; Wed, 4 Oct 2006 13:00:52 -0400 Received: from 172.17.3.236 ([172.17.3.236] helo=[172.17.3.236]) by ASSP-nospam; 4 Oct 2006 13:00:51 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <484EAC1B-4CC7-45FA-927B-1C534D0F4DE8@behanna.org> Content-Transfer-Encoding: 7bit From: Chris BeHanna Date: Wed, 4 Oct 2006 13:00:50 -0400 To: Pete French X-Mailer: Apple Mail (2.752.2) Cc: freebsd-amd64@freebsd.org, jasen.gibson@ge.com Subject: Re: suggestions for SATA RAID cards X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2006 17:00:59 -0000 On Oct 4, 2006, at 12:35 PM, Pete French wrote: >> I would guess that's nothing to do with blocks or striping per se. A >> single big file won't be laid out 'sequentially' on the disk; the >> filesystem tries to avoid filling up cylinder blocks. It puts enough >> in given places that the seek costs are pretty low. So, after >> reading >> one bit a while, it'll seek somewhere and start another read. The >> controller could issue that read to another component of the mirror; > > yes, the filesystenm layout may well make it leap around the > drives. But > what I am wanting to ensure is that if I issue a 128k block read to > the drives then it will satisfy this by reading two lots of 64k, > one from > each mirror, in parallel. If this is true, and if I am sequentially > reading blocks from a file, then even if the files moves about on > the drives, > the requests for blocks should always come from both drives at once. > > It isn't doung this, and I found a couple of interesting things - one > being the 'stripe size' parameter inside the RAID controller which > is set to 64k, and the oter being a comment somewhere that FreeBSD > never > issues more than 64k read requests at once. So I was speculating that > what is happening is that I am reading 64k chunks, and is this is less > than the stipre size then controller is almost always satisfying > these from > a single drive. Drives typically have a track buffer of 2-8MB, which is well in excess of the size of your read request. If a single drive can satisfy the entire read with a single seek and a partial rotation, then that's going to be faster than splitting the request up into two separate physical I/O requests, one per drive, involving two seeks and rotational latency of two drives. RAID-1 is going to shine when you have multiple parallel accesses to the volume, or when you're doing random I/O on a large file, or when the file is so large that you have to follow indirect blocks to get all of it. In those cases, both spindles are going to come to the party. Chris BeHanna