Ric Wheeler wrote:

quoted

Don't those thingies usually have NV cache or backed by battery such
that ORDERED_DRAIN is enough?

All of the high end arrays have non-volatile cache (read, on power loss,
it is a promise that it will get all of your data out to permanent
storage). You don't need to ask this kind of array to drain the cache.
In fact, it might just ignore you if you send it that kind of request ;-)

The size of the NV cache can run from a few gigabytes up to hundreds of
gigabytes, so you really don't want to invoke cache flushes here if you
can avoid it.

For this class of device, you can get the required in order completion
and data integrity semantics as long as we send the IO's to the device
in the correct order.

Thanks for clarification.

quoted

The problem is that the interface between the host and a storage device
(ATA or SCSI) is not built to communicate that kind of information
(grouped flush, relaxed ordering...).  I think battery backed
ORDERED_DRAIN combined with fine-grained host queue flush would be
pretty good.  It doesn't require some fancy new interface which isn't
gonna be used widely anyway and can achieve most of performance gain if
the storage plays it smart.

I am not really sure that you need this ORDERED_DRAIN for big arrays...

ORDERED_DRAIN is to properly order requests from host request queue
(elevator/iosched).  We can make it finer-grained but we do need to put
some ordering restrictions.

-- 
tejun