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 of
sectors 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: 39395
Average number of sectors discarded per call:
ext4: 43036 (21 MiB) XFS: 26.48 (13.2 KiB)
I made some TRIM performance measurements (see ssdperf.png attached)
with a small tool i wrote. (warning, destructive to data)
It looks like the OCZ needs a really high amount of time to execute
even the smallest TRIM command.
I made a small post about this here too: 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
xfs.txt
Description: Text document
ext4.txt
Description: Text document
ssdperf.png
Description: PNG image
trim_perf.c
Description: Text Data
| 