On Wed, Jun 20, 2012 at 06:39:38AM +1000, Dave Chinner wrote: > Exactly - XFS transactions are fine grained, checkpoints are coarse. > We don't merge extents freed in fine grained transactions inside > checkpoints. We probably could, but, well, it's complex to do in XFS > and merging adjacent requests is something the block layer is > supposed to do.... Last time I checked it actually tries to do that for discard requests, but then badly falls flat (=oopses). That's the reason why the XFS transaction commit code still uses the highly suboptimal synchronous blkdev_issue_discard instead of the async variant I wrote when designing the code. Another "issue" with the XFS discard pattern and the current block layer implementation is that XFS frees a lot of small metadata like inode clusters and btree blocks and discards them as well. If those simply fill one of the vectors in a range ATA TRIM command and/or a queueable command that's not much of an issue, but with the current combination of non-queueable, non-vetored TRIM that's a fairly nasty pattern. So until the block layer is sorted out I can not recommend actually using -o dicard. I planned to sort out the block layer issues ASAP when writing that code, but other things have kept me busy every since. _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
