From owner-freebsd-stable@FreeBSD.ORG Tue Jan 9 19:51:25 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D22A516A403 for ; Tue, 9 Jan 2007 19:51:25 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [216.148.227.151]) by mx1.freebsd.org (Postfix) with ESMTP id BF9FA13C455 for ; Tue, 9 Jan 2007 19:51:25 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from icarus.home.lan (c-71-198-0-135.hsd1.ca.comcast.net[71.198.0.135]) by comcast.net (rwcrmhc11) with ESMTP id <20070109195124m1100319t3e>; Tue, 9 Jan 2007 19:51:24 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 8A9A91FA037; Tue, 9 Jan 2007 11:51:24 -0800 (PST) Date: Tue, 9 Jan 2007 11:51:24 -0800 From: Jeremy Chadwick To: freebsd-stable@FreeBSD.ORG, ghelmer@palisadesys.com Message-ID: <20070109195124.GA72863@icarus.home.lan> Mail-Followup-To: freebsd-stable@FreeBSD.ORG, ghelmer@palisadesys.com References: <45A29EAD.5050308@palisadesys.com> <200701091737.l09HbGSZ026335@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200701091737.l09HbGSZ026335@lurza.secnetix.de> X-PGP-Key: http://jdc.parodius.com/pubkey.asc User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Subject: Re: 6.x loosing record of free space after filesystem fills? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2007 19:51:25 -0000 On Tue, Jan 09, 2007 at 06:37:16PM +0100, Oliver Fromme wrote: > Guy Helmer wrote: > > I think we've finally found the cause of the problem - it wasn't just > > occurring after heavy use, but was visible right after filesystem > > creation! We regularly built new filesystems with "newfs -U -O 1 -b > > 65536 -f 8192" > > Why are you using those blocksize and fragsize settings? > (If you store large files, then you should at least also > decrease the inode density, using the -i option.) Hmm... that begs the question: how do newfs -i and tunefs -f associate with one another? > Some time ago, Joe Greco wrote: > > > the one unusual thing about the configuration is that the filesystem > > > we are attempting to build on is a 136GB ccd across 4 scsi disks with > > > the fsize=8192 and the bsize=65536 (it is mainly to be used for large > > > data log files): > > > > FreeBSD doesn't support fsize/bsize so large. There are ongoing issues > > within the filesystem code and VM code that will cause such filesystems > > to break under heavy load. Matt Dillon also talked about this being less- > > than-optimal for the VM system from some technical points of view. > > It has been a while, and I'm not sure if there are still > problems with those non-standard fsize/bsize settings, but > I would definitely try to avoid them for production use. > > Best regards > Oliver Shouldn't we document this somewhere? Some places I can think of, off the top of my head: * newfs(8) manpage * http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-disk.html * http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/install-steps.html (this is debatable) If we need PRs + patches for this, I'll be more than happy to submit them. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |