Chris G. Demetriou wrote:
> 
> > FUA is a per-command bit. I haven't gone back and read the
> > spec, but I believe you can treat it as a "force write-through
> > cache" operation. I'm not sure what the effect on other
> > drive queued  (tagged) commands are.
> >
> > A FUA bit should probably reflect the (inverse) setting of B_ASYNC.
> > Again, *if* you have the drive set to a writeback policy.
> 
> Probably regardless of how the drive is set; it sounds like it's a
> safe thing to always set for non-async ops 

Yes. That *should* be the default.

> 
> Then there's the whole question of how something like this would
> interact with e.g. the 'soft updates' code, which manages buffer
> dependencies in the kernel.  I suppose that some of the issues raised
> could be dealt with via properly-tagged commands, but it sounds like
> additional thought may be needed...

Yes, HEAD of QUEUE vs. ORDERED tags.

Look- for the currently widely available drive sets out there,
it's not that critical an issue- you're not going to get more
than 4-16 commands per spindle before the drives just say enuff
already- but when you got to Fibre Channel with RAID boxes at
the other end, it would not be inconceivable to expect several
hundred commands being managed (particularly if the 'RAID' box
is in fact another system running in TARGET mode) from multiple
other initiators all at the same time, so clearly some thought
in terms of B_ORDER and all that stuff needs to be done (and
lord forgive me for this german-style sentence)....