Shared publicly  - 
 
Finally, SSDs are now being trimmed automatically out of the box. Embarrassingly late, but at least in time for 14.04 LTS.

(See https://blueprints.launchpad.net/ubuntu/+spec/core-1311-ssd-trimming)
51
19
Adal Alom Rodríguez's profile photoIvan Phan's profile photomargherita tiralongo's profile photoElijah Lynn's profile photo
26 comments
 
You can keep it if you prefer (the cron job will ignore mounts with "discard"), but on a desktop it seems generally preferrable to run from cron.
 
Very good. I already run a cron for this, but it seems better as an out-of-the-box job. Thanks
 
This is so wrong. This something the kernel should and not userspace be involved with.
 
+Lennart Poettering , that would mean to turn on "discard" on implicitly and always get the performance/battery life penalty. We can't impose functionality like "run this cleanup once a day/week/whatever else is suitable for that workload" on the kernel itself, surely?
 
+Martin Pitt Well, the kernel has all kinds of timers for file system and block device actions anyway. Flushing things out, and stuff like that. This really should be done by the kernel itself, maybe with a tunable in procfs or sysfs, but that's all. Userspace should not be involved in this.
 
I guess if it shouldn't be done in userspace one should inform Lukas Czerner and Karel Zak who wrote fstrim..
 
How much of a performance/battery life penalty is there running discard?
 
It's hard to say as it depends on the SSD and firmware, but we did see mass file deletions (such as removing entire kernel source trees) taking significantly longer with discard on some devices that don't support queued TRIM.   Also, some actions like heavy random file extend/shrink with ftruncate() were 3.5-4 x slower with discard on ext4.   Generally speaking though, discard overhead was minimal, but it does seem more efficient to batch up discards with periodic use of fstrim .
 
SSD's?! You kids with your new fangled technology. You'll pry my mechanical drive from me when it dies.
 
Spinny rust is painfully slow
 
+Colin King How does windows and osx handle the trim issue? I don't understand why there's such a big performance hit on linux :S 
 
I thought TRIM support with modern controllers causes ext IO\premature ware and tear and that garbage collection was something done on chip for modern SSD's? Can someone tell me why everyone thinks the kernel should be worrying about this what the drives do by themselves? 
 
+Derek Dickerson , the drive has no idea about which blocks the OS considers as unused. Disk drives don't "think" in terms of file systems, just in terms of reading and writing blocks.
 
My only concern with this is fstrim will cause a good 1-2 minutes of heavy I/O activity causing the system to slow down while the user has no idea what is going on or why.
 
can ubuntu perform trim command in kernel space adn not in user space mode?
 
Considering that SSD is widespread, this change comes too late. It should, by an update, input and versions 12.04.3, 13.04, 13.10
 
is it more efficient?how does windows or mac osx operates for trim?thanx
 
Hey does this mean Lubuntu 14.04 has SSD trim feature as a default...
i mean on the LXDE desktop environment in lubuntu 14.04....tentatively releasing on 17 April 2014
 
So trim support by default for LUX? 
Add a comment...