From owner-freebsd-fs@FreeBSD.ORG Wed Sep 26 20:20:05 2007 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F061016A417 for ; Wed, 26 Sep 2007 20:20:04 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail08.syd.optusnet.com.au (mail08.syd.optusnet.com.au [211.29.132.189]) by mx1.freebsd.org (Postfix) with ESMTP id 8C41D13C46E for ; Wed, 26 Sep 2007 20:20:04 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c220-239-235-248.carlnfd3.nsw.optusnet.com.au (c220-239-235-248.carlnfd3.nsw.optusnet.com.au [220.239.235.248]) by mail08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id l8QKJlam001667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Sep 2007 06:19:49 +1000 Date: Thu, 27 Sep 2007 06:19:47 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: "Rick C. Petty" In-Reply-To: <20070926171756.GB41567@keira.kiwi-computer.com> Message-ID: <20070927060725.O60903@delplex.bde.org> References: <46F3A64C.4090507@fluffles.net> <46F3B4B0.40606@freebsd.org> <20070921131919.GA46759@in-addr.com> <20070921133127.GB46759@in-addr.com> <20070922022524.X43853@delplex.bde.org> <20070926031219.GB34186@keira.kiwi-computer.com> <20070926175943.H58990@delplex.bde.org> <20070926171756.GB41567@keira.kiwi-computer.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org Subject: Re: Writing contigiously to UFS2? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2007 20:20:05 -0000 On Wed, 26 Sep 2007, Rick C. Petty wrote: > On Wed, Sep 26, 2007 at 06:37:18PM +1000, Bruce Evans wrote: >> On Tue, 25 Sep 2007, Rick C. Petty wrote: >> >>> On Sat, Sep 22, 2007 at 04:10:19AM +1000, Bruce Evans wrote: >>>> >>>> of disk can be mapped. I get 180MB in practice, with an inode bitmap >>>> size of only 3K, so there is not much to be gained by tuning -i but >>> >>> I disagree. There is much to be gained by tuning -i: 224.50 MB per CG vs. >>> 183.77 MB.. that's a 22% difference. >> >> That's a 22% reduction in seeks where the cost of seeking every 187MB >> is a few mS every second. Say the disk speed 61MB/S and the seek cost >> is 15 mS. Then we waste 15 mS every 3 seconds with 183 MB cg's, or 2%. >> After saving 22%, we waste only 1.8%. > > I'm not sure why this discussion has moved into speed/performance > comparisons. I'm saying 22% difference in CG size. Size is uninteresting except where it affects speed. "-i large" saves some disk space but not 22%, and disk space is almost free. "-b large -f large" costs disk space. >> Since I >> got to within 1% of the raw disk speed, there is little more to be >> gained in speed here. (The OP's problem was not speed.) > > I agree-- why are you discussing speed? I mean, it's interesting. But I > was only discussing CG sizes and suggesting using the inode density option > to reduce the amount of space "wasted" with filesystem metadata. The OP's problem was that due to an apparently-untuned maxbpg and/or maxbpg not actually working, data was scattered over all cg's and thus over all disks when it was expected/wanted to be packed into a small number of disks. Packing into a large number of small cg's should give the same effect on the number of disks used as packing into a small number of large cg's, but apparently doesn't, due to the untuned maxbpg and/or bugs. > I do think the performance differences are interesting, but how much of the > differences are irrelevant when looking at modern drives with tagged > queuing, large I/O caches, and reordered block operations? It depends on how big the seeks are (except a really modern drive would be RAM with infinitely fast seeks :-). I think any large-enough cylinder groups would be large enough for the seek time to be significant. Bruce