Date: Thu, 27 Sep 2007 06:19:47 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: "Rick C. Petty" <rick-freebsd@kiwi-computer.com> Cc: freebsd-fs@freebsd.org Subject: Re: Writing contigiously to UFS2? Message-ID: <20070927060725.O60903@delplex.bde.org> In-Reply-To: <20070926171756.GB41567@keira.kiwi-computer.com> References: <46F3A64C.4090507@fluffles.net> <46F3B4B0.40606@freebsd.org> <fd0em7$8hn$1@sea.gmane.org> <20070921131919.GA46759@in-addr.com> <fd0gk8$f0d$2@sea.gmane.org> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070927060725.O60903>