From owner-freebsd-stable@FreeBSD.ORG Wed Jan 10 11:57:09 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 361F516A407 for ; Wed, 10 Jan 2007 11:57:09 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.freebsd.org (Postfix) with ESMTP id 9B24A13C428 for ; Wed, 10 Jan 2007 11:57:08 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (eryjgx@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id l0ABv2R3089649; Wed, 10 Jan 2007 12:57:07 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id l0ABv2qq089648; Wed, 10 Jan 2007 12:57:02 +0100 (CET) (envelope-from olli) Date: Wed, 10 Jan 2007 12:57:02 +0100 (CET) Message-Id: <200701101157.l0ABv2qq089648@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG, ghelmer@palisadesys.com In-Reply-To: <45A3E3B9.4030205@palisadesys.com> X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Wed, 10 Jan 2007 12:57:07 +0100 (CET) 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 Reply-To: freebsd-stable@FreeBSD.ORG, ghelmer@palisadesys.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2007 11:57:09 -0000 Guy Helmer wrote: > Oliver Fromme wrote: > > 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 don't think that that theorie holds true in reality. Did you perform any benchmarks to verify it? In fact, I would expect the performance to be better when using a block size of just 8KB and a frag size of 1 KB. By the way, this is an excerpt from the tuning(7) manpage: | FreeBSD performs best when using 8K or 16K file system block | sizes. The default file system block size is 16K, which provides | best performance for most applications, with the exception of | those that perform random access on large files (such as database | server software). Such applications tend to perform better with | a smaller block size, although modern disk characteristics are | such that the performance gain from using a smaller block size | may not be worth consideration. Using a block size larger than | 16K can cause fragmentation of the buffer cache and lead to | lower performance. Guy Helmer wrote: > I wasn't aware of any known regressions in 6.x regarding large > filesystem block sizes... I'm not aware of any regressions either. 64 KB bsize and 8 KB fsize didn't work reliable in 4.x, and the situation doesn't seem to have gotten worse (maybe it has gotten better with UFS2, but I didn't perform extensive tests with it because the non-standard bsize/fsize pessimize performance anyway). Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "That's what I love about GUIs: They make simple tasks easier, and complex tasks impossible." -- John William Chambless