Re: discard and barriers

[Christoph Hellwig <hch@lst.de>]

On Sat, Aug 14, 2010 at 10:14:51AM -0400, Ted Ts'o wrote:
> Also, to be clear, the block layer will guarantee that a trim/discard
> of block 12345 will not be reordered with respect to a write block
> 12345, correct?

Right now that is what the hardbarrier does, and that's what we're
trying to get rid of.  For XFS we prevent this by something that is
called the busy extent list - extents delete by a transaction are
inserted into it (it's actually a rbtree not a list these days),
and before we can reuse blocks from it we need to ensure that it
is fully commited.  discards only happen off that list and extents
are only removed from it once the discard has finished.  I assume
other filesystems have a similar mechanism.

> And on SATA devices, where discard requests are not queued requests,
> the ata layer will have to do a queue flush *before* the discard is
> sent, right?

Yes.

> But things should be a tiny bit better even with SATA
> because we won't need to wait for the barrier to be acknowledged
> before sending more write requests to the device.  If I understand
> things correctly, the main place where this will have benefit will be
> for more advanced interfaces like SAS?

The performance improvement is primarily interesting for Fibre or iSCSI
attach arrays with thin provisioning support.  I've not seen a
TP-capable SAS device yet.  The other motivation is that this is the
last piece that relies on the ordering semantics of barriers, which
we're trying to get rid of.