Online TRIM/discard performance impact

Martin Rusko martin.rusko at gmail.com
Sat Nov 5 15:07:05 CDT 2011


Hello,

I wanted to ask if following performance drop with online discard
enabled for XFS is normal. I went through mailing list archives and
read information from Lukáš's page
(http://people.redhat.com/lczerner/discard/) so I was prepared for
some performance penalty. But this big?

--> Filesystem is mounted with noatime and discard options ...

/dev/sdb2 on /mnt/test-xfs type xfs (rw,noatime,discard)

--> Deleting freshly unpacked linux kernel sources ...

# time rm -rf linux-3.0.8

real	4m50.155s
user	0m0.012s
sys	0m0.940s

==> It took almost 5 minutes!

--> Deleting same freshly unpacked linux kernel sources this time with
filesystem mounted without 'discard' option ...

/dev/sdb2 on /mnt/test-xfs type xfs (rw,noatime)

# time rm -rf linux-3.0.8

real	0m1.023s
user	0m0.024s
sys	0m0.896s

==> It took a second and something.

SSD drive in question is one of the latest with SF-2281 chipset. I
expected, that TRIM function will just schedule sectors for garbage
collection, which happens some time later (during which drive can be
potentially slower). Trying the same tests with ext4 filesystem, it
got following numbers.

--> ext4 with 'discard' option ...

/dev/sdb3 on /mnt/test-ext4 type ext4 (rw,noatime,discard)

# time rm -rf linux-3.0.8

real	0m0.486s
user	0m0.012s
sys	0m0.468s

--> ext4 without 'discard' option ...

/dev/sdb3 on /mnt/test-ext4 type ext4 (rw,noatime)

root at layla:/mnt/test-ext4# time rm -rf linux-3.0.8

real	0m0.483s
user	0m0.020s
sys	0m0.460s

Tests were repeated several times and it was consistent. Deleting
files on XFS filesystem mounted with 'discard' option was painfully
slow. Kernel version was ...

   Linux layla 3.0.0-12-generic #20-Ubuntu SMP Fri Oct 7 14:56:25 UTC
2011 x86_64 x86_64 x86_64 GNU/Linux

Is this expected behavior?

Best Regards,
Martin




More information about the xfs mailing list