Skip site navigation (1)Skip section navigation (2)
Date:      29 May 1999 00:03:54 -0500
From:      Joel Ray Holveck <joelh@gnu.org>
To:        Don Lewis <Don.Lewis@tsc.tdk.com>
Cc:        Graeme Tait <graeme@echidna.com>, freebsd-hackers@FreeBSD.ORG, info@boatbooks.com
Subject:   FS tuning (Was: File system gets too fragmented ???)
Message-ID:  <86lne8h3gj.fsf@detlev.UUCP>
In-Reply-To: Don Lewis's message of "Thu, 27 May 1999 07:15:56 -0700"
References:  <199905271415.HAA10721@salsa.gv.tsc.tdk.com>

next in thread | previous in thread | raw e-mail | index | archive | help
> You might try unmounting the filesystem and doing
> 	tunefs -o space /dev/rawdevice
> (which can also be done at newfs time).  You may find that the
> performance, especially write performance, isn't too good.

I've been looking over FS performance tuning, trying to get my
compiles to go a bit quicker, and started wondering a few things.

As we all know, tunefs -o space will hurt write performance.  Will it
hurt read performance?  If I don't care about install-time speed, but
do care about run-time speed and free space, should I populate my
filesystems at install time with space tuning?

Is it possible to, on a restore, place down the directory tree with
dummy entries for regular files, so you don't get a split-up directory
when you populate it?  I know that mtree'ing the fs ahead of time
helps (and assume that mtree is breadth-first), but I don't recall any
of our utilities that do a breadth-first restore by default.  I don't
even see a utility to prepare a file list for tar in a breadth-first
manner; thoughts?

About a year ago, I heard discussions about the usefulness of tunefs.
Our OS has undergone lots and lots o' changes since then (unified
VM/buffer cache, CAM, etc).  newfs documents that rotdelay is useless,
but what about maxcontig?

About five minutes ago, I realized that one problem is that I recently
installed a new disk, and forgot to enable softupdates on it (doh!).
From the little I know, I don't quite understand why softupdates is a
tunefs parameter, instead of a mount flag.  Can a fs with softupdates
turned on in the superblock work on a non-softupdates kernel without
trouble?  If so, would it be a good idea to have newfs turn it on by
default?

Does bad144 have any space or time overhead?  Can it be disabled?

How do people like to set up their filesystems these days?  I've heard
of people who like one big fs (not generally usable anymore because of
the 1024 cyl limit), others who like the small root fs and one big fs
for everything else, and some who like separate fs's for different
things.  All other things (disk speed, etc) being equal, what's this
groups' opinion?

Huzzah! to Dyson et al for making our VM system self-tuning.  Any
thoughts about hints to give it?

Thanks,
joelh

-- 
Joel Ray Holveck - joelh@gnu.org
   Fourth law of programming:
   Anything that can go wrong wi
sendmail: segmentation violation - core dumped


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86lne8h3gj.fsf>