From owner-freebsd-fs@FreeBSD.ORG Sat Jun 10 00:07:08 2006 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA34916A41B for ; Sat, 10 Jun 2006 00:07:08 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 44D0143D83 for ; Sat, 10 Jun 2006 00:06:58 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout1.pacific.net.au (Postfix) with ESMTP id 2D62B329F9A; Sat, 10 Jun 2006 10:06:57 +1000 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5A06qiI021008; Sat, 10 Jun 2006 10:06:55 +1000 Date: Sat, 10 Jun 2006 10:06:51 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Scott Long In-Reply-To: <4489A8CC.8030307@samsco.org> Message-ID: <20060610091109.R14403@delplex.bde.org> References: <20060609065656.31225.qmail@web30313.mail.mud.yahoo.com> <200606091253.37446.mi+mx@aldan.algebra.com> <4489A8CC.8030307@samsco.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Mikhail Teterin , fs@freebsd.org Subject: Re: heavy NFS writes lead to corrup summary in superblock X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2006 00:07:08 -0000 On Fri, 9 Jun 2006, Scott Long wrote: > Mikhail Teterin wrote: >> When I tried to use the FS as a scratch for an unrelated thing, though, I >> noticed some processes hanging in nbufkv state. Google-ing led me to the: >> >> http://lists.freebsd.org/pipermail/freebsd-current/2003-June/004702.html >> >> Is this 3 year old advise *still* true? I rebuilt the kernel with BKVASIZE Probably. >> bumped to 64K (the block size on the FS in question) and am running another >> batch of dumps right now. When it is over, I'll check the df/du... > > Can you actually measure a performance difference with using the -b 65535 > option on newfs? All of the I/O is buffered anyways and contiguous data is > already going to be written in 64k blocks. I can measure a performance loss with larger block sizes, but mainly with small files, the default BKVASIZE, and larger fragment sizes too. On a WDC ATA drive which is quite slow for small block sizes (4K, 8K and 16K tansfer at 26MB/S and 32K+ at 49MB/S), a block/frag sizes of 32K/4K gives much the same throughput for copying /usr/src as does 16K/2K, but about half as much throughput for 32K/32K. I stopped benchmarking block sizes of 64K because old benchmarks showed that they only gave performance losses for /usr/src. With only large files, the fragment size shouldn't matter, but the block size shouldn't matter either once it is not too small, since files should be laid out contiguously and small blocks should be clustered into large ones efficiently. However, contiguous layout and clustering don't work perfectly and/or very efficiently, and using large block sizes like the default of 16K is an easy way to increase contiguity and reduce overheads for clustering. Fragmentation (discontiguity, not the fragmentation reported by fsck), tends to be very large for old, active file systems and typically reduces efficiency of trees like /home/ncvs by a factor of 5-10. Bruce