From owner-freebsd-fs@FreeBSD.ORG  Mon Jul  7 23:34:16 2003
Return-Path: <owner-freebsd-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 E69C637B401
	for <freebsd-fs@freebsd.org>; Mon,  7 Jul 2003 23:34:16 -0700 (PDT)
Received: from web80006.mail.yahoo.com (web80006.mail.yahoo.com
	[66.163.168.136])
	by mx1.FreeBSD.org (Postfix) with SMTP id 57DB243FBF
	for <freebsd-fs@freebsd.org>; Mon,  7 Jul 2003 23:34:16 -0700 (PDT)
	(envelope-from soundsampler@sbcglobal.net)
Message-ID: <20030708063416.53743.qmail@web80006.mail.yahoo.com>
Received: from [66.74.132.113] by web80006.mail.yahoo.com via HTTP;
	Mon, 07 Jul 2003 23:34:16 PDT
Date: Mon, 7 Jul 2003 23:34:16 -0700 (PDT)
From: Trent George <soundsampler@sbcglobal.net>
To: freebsd-fs@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Content-Filtered-By: Mailman/MimeDel 2.1.1
Subject: Re: Software Disk Cache Limit Issues
X-BeenThere: freebsd-fs@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Filesystems <freebsd-fs.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-fs>,
	<mailto:freebsd-fs-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-fs>
List-Post: <mailto:freebsd-fs@freebsd.org>
List-Help: <mailto:freebsd-fs-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-fs>,
	<mailto:freebsd-fs-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Jul 2003 06:34:17 -0000

Hi,
 
Since my last post I found a couple more interesting observations
 
1/ nswbuf_min has no effect on msdosfs (fat32) mounted filesystems like it did on ffs
 
this led me to beleive that it may be a metadata issue so:
 
2/ I experimented with newfs to see if blocksize, fragment size or ufs1, ufs2 effected the 
ratio of nswbuf's to usable hirunningspace.
 
the answer is no newfs settings effected the seeming fixed ratio of 65k of usable 
hirunningspace per nswbuf allocated on ffs filesystems
 
In summary:
a/ the default kernel has a max allocation of 256 nswbuf (in vfs_bio.c)
b/ this can be overridden with options NSWBUF_MIN=xxxx in custom kernel
c/ it seems the effect of a large sysctl vfs.hirunningspace gets capped on ffs filesystems
    by the size of nswbuf. and this always seems fixed at 64k per nswbuf
d/ fat32 filesystems seemed immuned from this "capping" effect
 
it seems the more i try to understand the relationship, the more mysterious it becomes.
it also seems that fat32 performance seems erratic and less re-producable with ffs
 
Trent