On Mon, Jun 04, 2012 at 09:46:26AM -0700, Brian Buhrow wrote:
> hello. From the description, it sounds like the amr(4) driver is
> really getting wedged somewhere and this is what's causing yor problem.
It sounds to me like either:
A) The amr -- due to driver or firmware issues, hard to say which -- has
gone from writeback to write-through mode and is thus performing
terribly on real workloads with random read and write traffic. Bonnie
is not a good tool for simulating this kind of workload. Actually, my
personal opinion is that Bonnie is not a good disk benchmarking tool for
any purpose at all. :-(
B) If you are using "log" mode with your FFS filesystems, it may be that
the cache-flush transactions performed by the WAPBL code are actually
causing a full flush of the amr's nonvolatile cache. If so, this is a
bug either in the firmware or the driver. If the cache has optimal
battery state, a synchronization requested by WAPBL should not cause it
to be flushed to the disks.
The adapter does show optimal battery status and write-back cache mode?
If so, I'd start investigating one of the two possibilities above. I bet
you can provoke the issue by, for example, doing a "dd" from the raw device
with a large block size to generate a steady stream of read traffic, and
then running postmark with the parameters adjusted to cause several minutes
of widely scattered I/O with a lot of directory transactions.