From owner-freebsd-questions@FreeBSD.ORG Tue Sep 19 17:29:47 2006 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D67A16A412 for ; Tue, 19 Sep 2006 17:29:47 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32FFC43D67 for ; Tue, 19 Sep 2006 17:29:42 +0000 (GMT) (envelope-from wmoran@collaborativefusion.com) Received: from collaborativefusion.com (mx01.pub.collaborativefusion.com [206.210.89.201]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wingspan with esmtp; Tue, 19 Sep 2006 13:29:42 -0400 id 0005642D.45102906.0000CAD6 Received: from Internal Mail-Server (206.210.89.202) by mx01 (envelope-from wmoran@collaborativefusion.com) with AES256-SHA encrypted SMTP; 19 Sep 2006 13:28:48 -0400 Date: Tue, 19 Sep 2006 13:29:40 -0400 From: Bill Moran To: Jerry McAllister Message-Id: <20060919132940.25b12b9d.wmoran@collaborativefusion.com> In-Reply-To: <20060919171355.GB18826@gizmo.acns.msu.edu> References: <1158683484.851.166.camel@ovirt.dyndns.ws> <20060919171355.GB18826@gizmo.acns.msu.edu> Organization: Collaborative Fusion X-Mailer: Sylpheed version 2.2.7 (GTK+ 2.8.20; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-questions@freebsd.org Subject: Re: Reducing reserved space on large filesystems X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2006 17:29:47 -0000 In response to Jerry McAllister : > On Wed, Sep 20, 2006 at 02:01:23AM +0930, Wayne Sierke wrote: > > > I was very interested to read the following written by Matthew Seaman in > > 2004. > > http://lists.freebsd.org/pipermail/freebsd-questions/2004-January/033754.html > > [snip] > > One thing you can do for any file system over about 256Mb is drop the > > free space reserve ('-m' option in newfs(8), or it can be modified in > > an existing filesystem using tunefs(8)). 1% is more than adequate if > > you're creating a multi-gigabyte filesystem. > > > > I'm especially interested in the comment about the 'free space reserve' > > which flies in the face of everything I can recall ever reading that has > > always mirrored the warnings in tuning(7) and tunefs(8) about the perils > > of reducing the reserved space below the default. However I didn't see > > any reply to Matthew's email to repudiate his statements. > > > > What are people's experiences in the field? Are the cautions now much > > less relevant with modern hard-drive capacities and performance? > > The free space reserve is most important on file systems that root > will need to write to in order to keep the system itself going. > In places that you put data that is fairly controlled, you can get > away with having a very small free space reserve, though some is > probably a good idea. Those tend to be the huge file systems where > having 8% or 10% reserved makes a big difference in the amount of > disk being tied up. >From "man tunefs": "o Settings of 5% and less force space optimization to always be used which will greatly increase the overhead for file writes. o The file system's ability to avoid fragmentation will be reduced when the total free space, including the reserve, drops below 15%. As free space approaches zero, throughput can degrade by up to a factor of three over the performance obtained at a 10% threshold." I believe those were the warnings that the OP spoke of. My understanding, for the research I've done, is that it's the _percentage_ of free space that's important, not the _amount_. Furthermore, if you manually force the optimization scheme to "time", these performance issues don't come in to play unless you actually fill the filesystem to within 15%. OTOH, I'm not aware of any recent research into whether or not this still applies. IIRC, those numbers were obtained using disks with sizes in the megabytes. It's possible that the percentages aren't linear, and that disks in the gigabytes don't have the same requirements. Sounds like a fun research project. I'll have to make some time to test it out. -- Bill Moran Collaborative Fusion Inc.