Poor performance using discard

[Peter Grandi]

[ ... ]

> Same again - aparently when you system goes idle, it burns a CPU in
> user time, but stops doing that when IO is in progress.

>> This time, I ran a sync.  That should mean all of the discard
>> operations were completed...right?

> Well, it certainly is the case for XFS. I'm not sure what is
> happening with ext4 though.

>> If it makes a difference, when I get the i/o hang during the
>> xfs deletes, my entire system seems to hang.  It doesn't just
>> hang that particular mounted volumes' i/o.

> Any errors in dmesg?

I had hoped that the OP would take my suggestions and runs some
web search, because I was obviously suggesting that there the
behaviour he saw is expected and correct for XFS:

>>> * Learn how TRIM is specified, and thus why many people prefer
>>>   running periodically 'fstrim' which uses FITRIM to mounting
>>>   with 'discard'.

So let's cut it short: the TRIM command is specified to be
synchronous.

Therefore a sequence if TRIM operations will lock up the disk,
and usually as a result the host too. In addition to this, in
some implementations TRIM is faster and in some it is slower,
but again the main problem is that it is synchronous.

Therefore using 'discard' which uses TRIM is subject to exactly
the behaviour reported. But 'ext4' batches TRIMs, issuing them
out of the journal, while XFS probably issues them with every
deletion operation, so 'ext4' should be hit less, but the
difference should not be as large as reported.

I suspect then that recent 'ext4' ignores 'discard' precisely
because of the many reports of freezes they may have received.

An early discussion of the issue with TRIM:

http://www.spinics.net/lists/linux-fsdevel/msg23064.html