From owner-freebsd-performance@FreeBSD.ORG  Thu Apr 24 18:37:13 2008
Return-Path: <owner-freebsd-performance@FreeBSD.ORG>
Delivered-To: freebsd-performance@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 44DC6106566C
	for <freebsd-performance@freebsd.org>;
	Thu, 24 Apr 2008 18:37:13 +0000 (UTC)
	(envelope-from freebsd@sopwith.solgatos.com)
Received: from parsely.rain.com (parsely.rain.com [199.26.172.196])
	by mx1.freebsd.org (Postfix) with ESMTP id DEC9E8FC1D
	for <freebsd-performance@freebsd.org>;
	Thu, 24 Apr 2008 18:37:12 +0000 (UTC)
	(envelope-from freebsd@sopwith.solgatos.com)
Received: from sopwith.solgatos.com (uucp@localhost)
	by parsely.rain.com (8.11.4/8.11.4) with UUCP id m3OI1X565667
	for freebsd-performance@freebsd.org;
	Thu, 24 Apr 2008 11:01:33 -0700 (PDT)
	(envelope-from freebsd@sopwith.solgatos.com)
Received: from localhost by sopwith.solgatos.com (8.8.8/6.24)
	id SAA11746; Thu, 24 Apr 2008 18:00:12 GMT
Message-Id: <200804241800.SAA11746@sopwith.solgatos.com>
To: freebsd-performance@freebsd.org
Date: Thu, 24 Apr 2008 11:00:12 +0100
From: Dieter <freebsd@sopwith.solgatos.com>
Subject: vfs.write_behind
X-BeenThere: freebsd-performance@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: freebsd@sopwith.solgatos.com
List-Id: Performance/tuning <freebsd-performance.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-performance>,
	<mailto:freebsd-performance-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-performance>
List-Post: <mailto:freebsd-performance@freebsd.org>
List-Help: <mailto:freebsd-performance-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-performance>,
	<mailto:freebsd-performance-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Apr 2008 18:37:13 -0000

The handbook says:

	The vfs.write_behind sysctl variable defaults to 1 (on).
	This tells the file system to issue media writes as full
	clusters are collected, which typically occurs when
	writing large sequential files. The idea is to avoid
	saturating the buffer cache with dirty buffers when it
	would not benefit I/O performance. However, this may
	stall processes and under certain circumstances you may
	wish to turn it off.

Looking through the documentation, I can't find an explaination
of what a cluster is.  Multiple blocks?

How would this stall processes?  Seems backwards.  If you don't
have write-behind, a process would block until the data gets
written to the media.

So if vfs.write_behind is 0, then a larger number of smaller
writes are issued?