discard and barriers

[Christoph Hellwig <hch@lst.de>]

Currently all filesystems submit their discard requests as
BLKDEV_IFL_WAIT | BLKDEV_IFL_BARRIER type requests.  That is they
both wait for completion synchronously, and submit them as a barrier.

For those not part of the current barrier discussion the barrier flag
has two implications:

 (a) it prevents reordering of the request with any previous or later
     one
 (b) it causes a cache flush before the request and ensures the request
     is on disk when it returns, which at least for typical SATA
     requests means another flush request as we don't able the FUA
     bit (which isn't applicable to TRIM or UNMAP anyway)

(a) is something we are planning to get rid of in the block layer
completely, so we'll need to figure out a way how to deal with it for
discards.  (b) doesn't actually seem to be nessecary for discards from
my research - given that discards are an optimization for the storage
device we don't care if it actually hits the disk or not in case of
a crash.  And given that the definition of SYNCHRONIZE_CACHE only deals
with data it's not even defined that it affects discard commands.

Can you guys review you rely on a) in your filesystem and if yes help
me to figure out a good way to replace it?  All the callers look like
they do not actually rely on it because they seem to wait for the
actual block freeing metadata I/O beforehand, but I'm not sure.