Re: Exposing FUA as alternative to DIOCCACHESYNC for WAPBL

[Edgar Fuß <ef%math.uni-bonn.de@localhost>]

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.