![](https://seccdn.libravatar.org/avatar/fc73f62928fc691da5a032a521db839b.jpg?s=120&d=mm&r=g)
On Thu, Mar 13, 2014 at 1:10 PM, Greg Freemyer wrote:
C
wrote: On Thu, Mar 13, 2014 at 9:26 PM, Jason
wrote: As for the discard, few people have told me in the past few days not to use it and considering they know what they're talking about I'm not questioning it so I have personally removed it.
The only reason I can think of that someone would suggest not using discard is that it can impact the speed of deleting content off the drive. https://patrick-nagel.net/blog/archives/337
That blog post is directly on point for why I recommended fstrim over discard.
As I put in an earlier email, until recently all SSDs implemented trim as a non-queue-able command, so every trim command triggered a internal drive cache flush. Per that blog post that caused a 40x increase in time to delete an unpacked kernel tree. Ie. It makes ext4 perform like xfs of 3 years ago.
Newer SSDs may have finally implemented trim as a queue-able command and thus the cache flush is no longer done. For them discard should be a fine option, but I've seen no benchmarks.
Unfortunately I don't know how to know which way a SSD has the trim command implemented. Maybe do what the blog author did and test untar'ing and deleting a kernel tarball. Be sure to include the time for sync after rm -r.
I'm willing to time test the discard thing on my system (on the Samsung 840 Pro)... but it will have to wait for at least 3 weeks (travelling starting pretty much.. now). I haven't noticed any speed impact, but then again, I don't usually untar and then delete the kernel source (or do similar large tasks). C. -- openSUSE 13.1 x86_64, KDE 4.12 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org