trim performance on xfs (also reply to: Online TRIM/discard performance impact)

[Andrei Purdea]

I also recently met with an issue that has been described in a
previous email(http://oss.sgi.com/archives/xfs/2011-11/msg00108.html).
I have an OCZ Agility 3 (also a SandForce 2281 controller),and a
Corsair Performance Pro (non-SandForce controller,with good
non-compressible data speeds)
Removing a linux-3.2-rc5 tree took more then 6 minutes with online
discard,and ext4 was very speedy (less then a second), but only on the
SandForce controller!!For the Corsair performance was good on both
filesystems.
So I decided to debug what is happening.I also noticed that fstrim was
slower on the OCZ(30-40 seconds, vs. 3 seconds on the Corsair)So I had
a hunch that the performance difference comes from the number
ofsectors that are discarded in a single TRIM command.
So i compiled a kernel where I inserted a printk into
blkdev_issue_discard(),to see how many sectors each call asks for.
Results:
Total number of sectors discarded:   ext4: 1032864   XFS: 1043112
(about the same)Number of calls to blkdev_issue_discard():   ext4: 24
          XFS: 39395Average number of sectors discarded per call:
ext4: 43036 (21 MiB)   XFS: 26.48  (13.2 KiB)
I made some TRIM performance measurements (see image on
http://purdea.ro/projects/trim_perf/)with a small tool i wrote.
(warning, destructive to data)
It looks like the OCZ needs a really high amount of time to
executeeven the smallest TRIM command.
I made a small post about this here: http://purdea.ro/projects/trim_perf/
Can this be fixed in XFS?
I am curious, do all SandForce controllers exhibit this slow TRIM issue?
Andrew
-- 
Purdea Andrei
http://purdea.ro
student at the “Politehnica” University of Timisoara
Faculty of Automation and Computers (AC)
Master's Degree Program - Computer Engineering (MCE)
2nd year