Date: Wed, 3 Apr 1996 22:34:29 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: s_koyin@eduserv.its.unimelb.EDU.AU (HMG coA reductase) Cc: freebsd-questions@FreeBSD.ORG Subject: Re: sysinstall's newfs Message-ID: <199604040534.WAA20965@phaeton.artisoft.com> In-Reply-To: <199604040305.NAA10219@eduserv.its.unimelb.EDU.AU> from "HMG coA reductase" at Apr 4, 96 01:05:04 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604040534.WAA20965>