From owner-freebsd-questions Wed Apr 3 21:40:48 1996 Return-Path: owner-questions Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA27703 for questions-outgoing; Wed, 3 Apr 1996 21:40:48 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id VAA27687 for ; Wed, 3 Apr 1996 21:40:45 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id WAA20965; Wed, 3 Apr 1996 22:34:29 -0700 From: Terry Lambert Message-Id: <199604040534.WAA20965@phaeton.artisoft.com> Subject: Re: sysinstall's newfs To: s_koyin@eduserv.its.unimelb.EDU.AU (HMG coA reductase) Date: Wed, 3 Apr 1996 22:34:29 -0700 (MST) Cc: freebsd-questions@FreeBSD.ORG In-Reply-To: <199604040305.NAA10219@eduserv.its.unimelb.EDU.AU> from "HMG coA reductase" at Apr 4, 96 01:05:04 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-questions@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > G'day all. I have some observations regarding the state of the filesystem > after installing a new copy of FreeBSD. Apparently the sysinstall defaults > for newfs are grossly inappropriate and lead to a badly optimised file- > system. > > Here is the report from disklabel: [ ... unused sectors caused by slices falling on partial cylinder group boundries causing up to 4095 (worst case) sectors to be unused ... ] This is an artifact of your partitioning choices. It's really up to you to make sure you use 4k increments (the default cylinder group assumptions). Really, the major fix is a rewrite of all the disk management code, after some underlying technology gets worted out. > Some note worthy points are: > 1. Absence of rotational position table This is less useful than it used to be when seeks were relatively fast and rotation was slow. For ZBR drives (ie: most modern drives) or geometry translated drives (ie: most IDE drives), this is simply useless (see below). > 2. ntrak value of 1, which should be equal to the no. of heads, or > tracks per cylinder. > 3. nsect == npsect == spc which does not tally with the disklabel values. These values are used to *disable* seek optimization. This is because with physical geometries that are non-linear, or are not detectable because the controller or drive hardware itself lies, seek optimization is actually pessimization. This is because if you optimize to assume a particualr n/n+1 sector crossing is going to take a relatively long time, you will be wrong almost all of the time on any modern disk. It is possible to go to a 32k sized table for a ZBR recorded drive up to 8G and actualy reeenable seek optimization to positive effect, but only for SCSI II drives which implement physcical geometry queries. This hasn't been implemented yet, but, of course, if it were, the disktab wouldn't apply -- the disktab would have to be taken "out of the loop" for those drives. Interleave optimizations are also a no-no on moder disks, which have track buffers and begin reading immediately after the seek and stop when the get to the sector you asked for -- sector order is reversed, and counts dowm so that sequential reads (or extents) end up wholly in the track buffer on these drives. That way, subsequent reads following the previous one will always get a cache hit. Optimizing seeks this way without knowledge of actual sector offsets where seeks are required actually causes the track buffer to be flushed *more frequently* than it would *without* optimization. > I'm wondering if anyone has noticed such things, and how you've handled it. We handled it by causing it. 8-). > I reinstalled the entire system, mounted the FIXIT floppy and newfs > both partitions manually using most of the newfs options (can't remember them) > and then managed to improve the fs. Is this a `feature' of sysinstall or > is there something wrong with my system or disk or whatever? This is a feature on anything but old drives, where the seek optimizations are actually effective. The Osterhout and Sun papers show that the clustering optimization *dwarfs* all of the other optimizations combined, by an order of magnitude. We still do clustering, we just disable the things which actually *hurt* performance for typical users. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.