Software Disk Cache Limit Issues

[Bruce Evans]

On Mon, 7 Jul 2003, Trent George wrote:

> 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:

This is because the implementation of msdosfs is too primitive and/or old
to support write (or read) clustering.  Try turning off write clustering
for ffs (mount -u -onoclusterw... ...).  The default ffs block size is now
a relatively large fraction of the cluster size (16K / 64K or 16K / 128K),
so perhaps clustering is not doing anything useful for ffs anyway.  It
would be much more useful for msdosfs with a block size of 512.  I think
read clustering is less than useful with normal block sizes for most
current drives, since caching in the drives is effective, but write
clustering is still useful if the drives' write cache is turned off.

> 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

I think you mean 64K.  64K is the cluster size.  It is the drive[r]'s
si_iosize_max, which defaults to DLTPHYS = 64K but may be larger.  It
should be 128K for ATA drives.  Other values are unusual.

> 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

The quick fix seems to be to use this, and fix the setting of
vfs.hirunningspace and any associated variables to be consistent with
it (either using sysctl or in the sources).  Changing nswbuf and nbuf
to track changes to vfs.hirunningspace, etc. is not so easy.

Bruce