I've whacked disk-level transaction clustering into
the sd and wd drivers of -current from about 3 days ago.
This is before the gehenna-devsw merge, so I dunno whether
the patches I've put up will apply as of today.

I've only tested the sd driver, I haven't yet tried
compiling the wd driver with clustering enabled.
And only on an FFS partition w/o softdeps enabled.

For a simple benchmark, I used ssh/pax to copy a full-ish
/usr/src/sys tree (it had the kernels from a release build
in it) onto a test machine where sd clustering was enabled.
About 99K total xfers were done to disk.  Of these, about
1300 were clusters built by the sd driver.  These 1300
clusters held about 5100 buffers that would have been
individually scheduled if the driver weren't combinging
them.  So, clustering saved about 3800 xfers, roughly a
4% savings.

I then built the GENERIC kernel with clustering disabled.
About 12800 xfers were done during the build.  Building
GENERIC again with clustering turned on did about 12200 xfers,
where 1000 buffers or so were combined into 300 clusters.
That's about a 5% savings.  CPU time and wall time for both
compiles were comparable.

None of this is earth-shattering news, of course, but it does
demonstrate that clusters can be missed at the FS/VM interface.
And that's when only one process uses the disk in question.

If someone points me at some benchmarks enjoyed by the powers
that be, I'll be glad to generate harder numbers.  See a msg
posted a few days back on what/how I'd test.

Further info and code/patches at

    http://www.blasted-heath.com/nbsd/cluster/

I had to hand edit the patch to remove some lines in
sys/conf/files and the like that weren't relevant to
clustering, so there's a chance that part of the patch
might not apply cleanly.  If you try it, let me know how
it goes.

Chris <jepeway@blasted-heath.com>.