From owner-freebsd-stable@FreeBSD.ORG Tue Jan 9 18:49:36 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 EEA4E16A407 for ; Tue, 9 Jan 2007 18:49:36 +0000 (UTC) (envelope-from ghelmer@palisadesys.com) Received: from magellan.palisadesys.com (magellan.palisadesys.com [192.188.162.211]) by mx1.freebsd.org (Postfix) with ESMTP id 9DF6613C44C for ; Tue, 9 Jan 2007 18:49:36 +0000 (UTC) (envelope-from ghelmer@palisadesys.com) Received: from [172.16.2.242] (cetus.palisadesys.com [192.188.162.7]) (authenticated bits=0) by magellan.palisadesys.com (8.13.8/8.13.8) with ESMTP id l09InNXq075709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Jan 2007 12:49:23 -0600 (CST) (envelope-from ghelmer@palisadesys.com) Message-ID: <45A3E3B9.4030205@palisadesys.com> Date: Tue, 09 Jan 2007 12:49:29 -0600 From: Guy Helmer User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: freebsd-stable@freebsd.org, ghelmer@palisadesys.com References: <200701091737.l09HbGSZ026335@lurza.secnetix.de> In-Reply-To: <200701091737.l09HbGSZ026335@lurza.secnetix.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (magellan.palisadesys.com [192.188.162.211]); Tue, 09 Jan 2007 12:49:23 -0600 (CST) X-Palisade-MailScanner-Information: Please contact the ISP for more information X-Palisade-MailScanner: Found to be clean X-Palisade-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-4.399, required 6, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_00 -2.60) X-Palisade-MailScanner-From: ghelmer@palisadesys.com 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 18:49:37 -0000 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.) > These settings were chosen to optimize I/O throughput for Postgresql on the theory that a 64KB block size would maximize disk throughput in the general case (especially for a RAID 10 system) and an 8K frag size would match Postgresql's page size. I wasn't aware of any known regressions in 6.x regarding large filesystem block sizes... > 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 > > Thanks, Guy