From owner-freebsd-current@FreeBSD.ORG Sat Jan 2 01:53:38 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FCDE106566B; Sat, 2 Jan 2010 01:53:38 +0000 (UTC) (envelope-from james-freebsd-current@jrv.org) Received: from mail.jrv.org (adsl-70-243-84-13.dsl.austtx.swbell.net [70.243.84.13]) by mx1.freebsd.org (Postfix) with ESMTP id 890CF8FC18; Sat, 2 Jan 2010 01:53:38 +0000 (UTC) Received: from kremvax.housenet.jrv (kremvax.housenet.jrv [192.168.3.124]) by mail.jrv.org (8.14.3/8.14.3) with ESMTP id o021raZm036346; Fri, 1 Jan 2010 19:53:36 -0600 (CST) (envelope-from james-freebsd-current@jrv.org) Authentication-Results: mail.jrv.org; domainkeys=pass (testing) header.from=james-freebsd-current@jrv.org DomainKey-Signature: a=rsa-sha1; s=enigma; d=jrv.org; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=mPjn7dhkCqKAkbRph8w7cXrcO0kocS4mK6hNwE1fZUEbP92zyDlKtd9ccOB/RNffg AnfY42bM3x+hujXnBEXpr8ksm1tFyrPhX3+lJbg09mHagDycXHbJ//qE+nwtpLNTRas +Au5gy1lCVKOJC0X62BuJpA4ScojUkNgHssl2+Y= Message-ID: <4B3EA720.8070803@jrv.org> Date: Fri, 01 Jan 2010 19:53:36 -0600 From: "James R. Van Artsdalen" User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Scott Long References: <65036.1262386032@critter.freebsd.dk> <925A0DA7-5D9B-41FA-B586-6C128F816C58@samsco.org> In-Reply-To: <925A0DA7-5D9B-41FA-B586-6C128F816C58@samsco.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: File system blocks alignment X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jan 2010 01:53:38 -0000 Scott Long wrote: > It's all about read latency in the read-modify update operation. In this case it's about rotational latency - read/modify/write necessarily adds a full rotation onto the I/O time, above and beyond the read latency. At 5400 rpm that's 11 ms added. To an extent this can be masked by deferring the write and doing other I/O until the disk rotates to a favorable position (a short seek is faster than a rotation). But the cache is only so big and the drive may have to take the hit and do the writes even at an unfavorable point if something like newfs saturates the cache. I am surprised the hit is so bad. I guess we'd have to look at a trace-tape of the I/O but I would have expected many of the writes (after r/m/w) from newfs and restore to be combined in each cg, and many reads eliminated due to data already being cached via speculative reads (while waiting for the disk to rotate for a write the drive might as well read what's passing under the head and cache it). (of course, the bad hit may just be the result of v1.0 firmware, or on-drive processors that turned out to be too slow for efficient r/m/w algorithms under real-world loads) Faster rotation rates win, but the bit-density goes down at higher speeds. So a 15k SAS drive may be faster than a 7200 rpm but it's nowhere near twice as fast.