On Tue, Jun 19, 2012 at 02:48:59PM -0400, Mike Snitzer wrote:
On Tue, Jun 19 2012 at 10:44am -0400,
Mike Snitzer<snitzer@xxxxxxxxxx> wrote:
On Tue, Jun 19 2012 at 9:52am -0400,
Spelic<spelic@xxxxxxxxxxxxx> wrote:
I do not know what is the mechanism for which xfs cannot unmap
blocks from dm-thin, but it really can't.
If anyone has dm-thin installed he can try. This is 100%
reproducible for me.
I was initially surprised by this considering the thinp-test-suite does
test a compilebench workload against xfs and ext4 using online discard
(-o discard).
But I just modified that test to use a thin-pool with 'ignore_discard'
and the test still passed on both ext4 and xfs.
So there is more work needed in the thinp-test-suite to use blktrace
hooks to verify that discards are occuring when the compilebench
generated files are removed.
I'll work through that and report back.
blktrace shows discards for both xfs and ext4.
But in general xfs is issuing discards with much smaller extents than
ext4 does, e.g.:
THat's normal when you use -o discard - XFS sends extremely
fine-grained discards as the have to be issued during the checkpoint
commit that frees the extent. Hence they can't be aggregated like is
done in ext4.
As it is, no-one really should be using -o discard - it is extremely
inefficient compared to a background fstrim run given that discards
are unqueued, blocking IOs. It's just a bad idea until the lower
layers get fixed to allow asynchronous, vectored discards and SATA
supports queued discards...
