From owner-freebsd-hackers Sun Mar 31 13:30:26 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA29358 for hackers-outgoing; Sun, 31 Mar 1996 13:30:26 -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 NAA29348 for ; Sun, 31 Mar 1996 13:30:18 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA11913; Sun, 31 Mar 1996 14:26:38 -0700 From: Terry Lambert Message-Id: <199603312126.OAA11913@phaeton.artisoft.com> Subject: Re: Lowering minfree to 1% on large disks To: taob@io.org (Brian Tao) Date: Sun, 31 Mar 1996 14:26:38 -0700 (MST) Cc: freebsd-hackers@FreeBSD.org In-Reply-To: from "Brian Tao" at Mar 31, 96 01:49:15 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-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > I know the tunefs man page contains warnings about lowering the > minfree threshold on a disk to below 5%, but besides file write > performance, is there any other reason *not* to drop it down to 1 or > 2 percent? Because this is below the hard-coded hysteresis range in which the FS will automatically switch between "time" and "space" optimization. If you do this, it will cause the FS mode to toggle constantly. > The specific application is with FTP filesystems. I have a couple > of 4GB disks for our mirror archives and I wouldn't mind recovering > the 300MB or so on each drive. Yeah, disk is cheap, but it still > seems like a waste to me. > > Since the only writes occuring on those drives come from the > mirror process, I figure network performance will always be the > bottleneck rather than disk writes. The reason for the reserve is fragmentation. Effectively, the choice of where to write is a hash onto the disk. For a decreasing reserve, the liklihood of a hash collision increases expotentially, and this will hurt preformance significantly. The 50% collision probability mark for a straight hash is ~85% (Knuth, _Sorting And Searching_). A free reserve of 10% was settled on by people who, like you, didn't want to "waste space'. In reality, you are trading hash reserve for fragmentation wastage by dropping the reserve. 8% is a little iffy, 5% is downright foolish for the 5% before you hit the reserve, and 1% or 2% *will* cause *severe* fragmentation. Are you prepared to write a defragmenter? No one has written one yet because they didn't need one -- they didn't try tuning their reserve down to 1% or 2%. If you do, you'll need one. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.