>
> block, so I can't see what would ever read in such a >8K buffer anyhow.
>
vfs_cluster does that.  It does additional frobbing to hide larger
read-ahead buffers.  In Net/OpenBSD the frobbing appears to get
undone at iodone time.  (FreeBSD does things differently, with a similar
effect.)  The Lite/2 code frobbs existing buffers, while FreeBSD creates
temporary, physical I/O buffers for providing a place to cluster.

> 
> I just did a bunch of dd's from raw (shouldn't do anything, right?) and block
> devices with bs=16k and bs=64k.  Still no buffers larger than 8K in the buffer
> cache.
> 
The static size of the buffers is driven by the filesystem code.  UFS 8K/1K
doesn't create >8K buffers.  If you use a 16K/2K filesystem or MSDOS, you
can readily get a 16K buffer (or big MSDOS partitions, you can get even
larger.)  Vfs_cluster modifies the buffers only temporarily for larger
sizes.  It uses the first (or last) buffer -- I forget, (in non-FreeBSD
systems) as a "mother buffer", only during I/O.  Filesystems generally
create buffers that are aligned and are the logical block size -- except
the last in a file.

> So what did increasing MAXBSIZE change, exactly?  I must be misunderstanding
> something very fundamental.  Please humor me.
> 
Mostly fixes usage of MSDOS FS with > 16K cluster size.  It also upps the
limit for cluster sizes (as used by vfs_cluster.)

>
> A more surprising revelation is that the AGE list is always empty.  Again, is
> this correct?  Why?
> 
We realized that on FreeBSD several years ago, and found that the AGE
processing was broken.  It is possible to fix it, but FreeBSD has an
alternative scheme for aging that works (doesn't do exactly the same thing,
but has some positive attributes.)  Implementing the AGE queue correctly
as originally envisioned is tricky, and as I remember, almost every
implementation might be broken (including, the "HEAVY" releases.)  I don't
know if NetBSD's is working correctly or not.  The AGE thing is really
problematical though.

John
dyson@freebsd.org