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 _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
