From owner-freebsd-hackers Fri May 28 22: 4:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from detlev.UUCP (tex-100.camalott.com [208.229.74.100]) by hub.freebsd.org (Postfix) with ESMTP id E276514D5A for ; Fri, 28 May 1999 22:04:40 -0700 (PDT) (envelope-from joelh@gnu.org) Received: (from joelh@localhost) by detlev.UUCP (8.9.3/8.9.3) id AAA02801; Sat, 29 May 1999 00:04:07 -0500 (CDT) (envelope-from joelh) To: Don Lewis Cc: Graeme Tait , freebsd-hackers@FreeBSD.ORG, info@boatbooks.com Subject: FS tuning (Was: File system gets too fragmented ???) References: <199905271415.HAA10721@salsa.gv.tsc.tdk.com> From: Joel Ray Holveck Date: 29 May 1999 00:03:54 -0500 In-Reply-To: Don Lewis's message of "Thu, 27 May 1999 07:15:56 -0700" Message-ID: <86lne8h3gj.fsf@detlev.UUCP> Lines: 54 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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