Date: Sat, 12 Jul 1997 09:05:41 -0700 (PDT) From: "Rodney W. Grimes" <rgrimes@GndRsh.aac.dev.com> To: gpalmer@FreeBSD.ORG (Gary Palmer) Cc: gurney_j@resnet.uoregon.edu, dlowe@sirius.com, freebsd-isp@FreeBSD.ORG Subject: Re: INN on an async-mounted spool? Message-ID: <199707121605.JAA24600@GndRsh.aac.dev.com> In-Reply-To: <2392.868676269@orion.webspan.net> from Gary Palmer at "Jul 11, 97 10:57:49 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> > you also might want to look at using cdd to give your spools multiple > > disks to work on... the more spindles the better.. but make sure that > > the strip size is 32megs (or whatever the size of a cylinder group is) > > to get the best performance... > > Just a note here: I'm not *100%* sure that a 32Mb stripe size is > right. While on the face of it Joe's arguments in support of it make > sense, I have yet to see any figures to support his assertions. I > agree 100% that small stripes, as used by hardware controllers (e.g. 4 > or 8k) are useless in the face of a full feed (unless you happen to > stripe more drives together than most people see in a year). I just > think 32Mb is going a bit too far in the other direction. I was the one who talked with Joe about the block interleave value that should optimize a ccd array for transactions. I told him to use a ``cylinder group'' as the interleave size. He ran some benchmarks and sure enough, it was much better at that size than anything smaller. The rational that this is optimal is that UFS/FFS tries to store both the meta data and the datablocks in the same cylinder group, if you are trying to optimize ``news transaction rate'' you want the whole transaction to hit one drive so that you can have a transaction occuring on each of the drives in the ccd. If you use anything smaller than a ``cylinder group'' as the interleave factor there is a very high probability that a single transaction hits 2 drives creating drive contention in the array. Then once Joe started passing this out the ``cylinder group size'' has become 32MB as a simplification of the original idea, and actually holds since the newfs -u parameter has been defaulted to 4096 blocks (yeilding a 16 cyl/group * 4096 blk/cyl = 65536blk/grp or 32MB/group. This 32MB value is _wrong_ if you change any of the default cylinder group stuff when newfs'ing. Also one could run a whole sweep of cgsize vs interleave factor and I suspect your resulting data would say that maximal transaction rate occurs for any interleave >= cgsize up to a certain maximal where it should start to fall off. Looking over the original Berkeley RAID papers will confirm my above statements. Pay attention to the part about optimizing for transaction rates, not throughput. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation, Inc. Reliable computers for FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707121605.JAA24600>