Date: Sat, 29 May 1999 01:26:21 -0400 (EDT) From: Brian Feldman <green@unixhelp.org> To: Joel Ray Holveck <joelh@gnu.org> Cc: Don Lewis <Don.Lewis@tsc.tdk.com>, Graeme Tait <graeme@echidna.com>, freebsd-hackers@FreeBSD.ORG, info@boatbooks.com Subject: Re: FS tuning (Was: File system gets too fragmented ???) Message-ID: <Pine.BSF.4.10.9905290122290.77444-100000@janus.syracuse.net> In-Reply-To: <86lne8h3gj.fsf@detlev.UUCP>
next in thread | previous in thread | raw e-mail | index | archive | help
On 29 May 1999, Joel Ray Holveck wrote:
> > 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?
It /might/ even make it faster to read. Don't shoot me if this isn't the case!
>
> 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?
I don't think it should be turned on by default, since legacy fsck code cannot
handle SoftUpdates inconsistencies anywhere nearly as well as Kirk's rewrite
does it all. It's a mount flag (as I understand it) so that utilities can
find out if the FS was running SoftUpdates in the case of a crash. The
flag is harmless to an old kernel, which would just ignore it.
>
> Does bad144 have any space or time overhead? Can it be disabled?
I'm pretty sure bad144 doesn't even apply to current disks.
>
> 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?
My opinion (for a simple user box) is to separate into smaller, maintainable
/ /tmp /var, and large /usr and /home (etc etc).
>
> 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
>
Brian Feldman _ __ ___ ____ ___ ___ ___
green@unixhelp.org _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve! _ __ | _ \ _ \ |) |
http://www.freebsd.org _ |___)___/___/
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?Pine.BSF.4.10.9905290122290.77444-100000>