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. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
