Some comments as I probably count as one of the larger WAPBL consumers (we have ~150 employee's Home and Mail on NFS on FFS2+WAPBL on RAIDframe on SAS):
DH> E.g. I'm not convinced that writing out journal blocks synchronously DH> one at a time will be faster than flushing the cache at the end of a DH> journal write, even though the latter inflicts collateral damage in DH> the sense of waiting for perhaps many blocks that don't need to be DH> waited for. I'll be happy to instrument this in Real Life (see above) if that helps. JD> Indeed - writing journal blocks sync one by one is unlikely to be JD> faster then sending them all async and doing cache flush on the end, JD> that wouldn't make sense. Journal blocks are not written one by one (you starve a RAID to death with that), but coalesced into (mostly) 64k chunks aligned with FS blocks (which normally are aligned with RAID stripes or you're dead anyway). Also, I remember each journal flush to actually cause two cache syncs, one before and one after writing the actual data. JD> it adds (another) incentive to actually integrate AHCI NCQ support What about SCSI TCQ? I seem to remember all that flushing could be avoided if the FS used queueing. DHs comments on barriers seem to second that.