[....]
> Any errors in dmesg?
None
>
> Also, I think you need to provide a block trace (output of
> blktrace/blkparse for the rm -rf workloads) for both the XFS and
> ext4 cases so we can see what discards are actually being issued and
> how long they take to complete....
Here's the output from running similar
commands as Christoph:
blkparse xfs.trace.blktrace.* | grep -w D | wc -l
1134996
blkparse ext4.trace.blktrace.* | grep -w D | wc -l
27240
Attached archives of most of the ext4 results.
>
> Cheers,
>
> Dave.
Peter was right then. Per multiple recommendations
I'm switching to fstrim, it is quicker than the deletes.
time fstrim -v /usr
/usr: 9047117824 bytes were trimmed
real 0m56.121s
user 0m0.110s
sys 0m0.000s
The subsequent runs consistently takes about a minute to run on a 40GB
volume.
time fstrim -v /usr
/usr: 9047117824 bytes were trimmed
real 0m56.121s
user 0m0.090s
sys 0m0.000s
I see that the running of fstrim was already discussed
http://oss.sgi.com/archives/xfs/2011-05/msg00338.html.
Please add something to the FAQ about using SSDs. It would be great if
people could see the recommended mount options and fstrim crontab entry
(or other option) for running xfs on a SSD.
Thanks for the input and patience.
~tom
ext4.trace.blktrace.tar.bz
Description: application/bzip-compressed-tar
signature.asc
Description: This is a digitally signed message part
|