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