Wandering if my machines are well set for SSD's I felt in confusion reading all around the web various chapters of the story ... with no number.

There I won't question the need for TRIM because as we'll see below, although the defaults in Ubuntu 14.04 is disable, options were brought to enable it when possible, so I guess it is desirable and I believe an unwanted feature would never have generated so much to read.

What I understood (maybe all is wrong, surely some is wrong) : because of poor performance in kernel handling via fstab+discard way compared to Windows immediate trim-on-delete, activation in ubuntu was postponed until Trusty. And even in Trusty, activation was limited to Intel and Samsung SSD vendors if we believe the fstrim-all manual (an other chapter here is there were critical bugs in some SSD firmwares). fstrim-all [wa|i]s the helper cron tool that carries this limitation and also that bypass[es|ed] us for the need to understand what a file-systems (and FS support for TRIM) and mount-points are to answer one's question like "if my 2 partitions / & say /home are on the same SSD, do I have to run fstrim / /home or fstrim / is enough?". all in "dash-all" stands for all compatible mount-points (as well as all brands with help of a single -no-model-check parameter). This limited white-list (in man) was (and is still) more conservative than the one fstrim-all script !!! which has 2~4 vendor more, which in turn is more restrictive than the one in ext4 (if ever) or kernel (well it couldn't be less). Today some say there is no more white-list. Do they mean in -all and/or fstrim binary (if ever there where here) and/or kernel ?

Confusion I said : is it because one of my machines is a ubuntu certified one with no-Samsung no-Intel no-OCZ no-Patriot no-SanDisk, where beside the /etc/cron.weekly/fstrim that runs fstrim-all I find a trim script that bypasses all util-linux limitations by running a simple fstrim -v / >> /var/log/trim.log ? I can't remember I did that my self. I really removed the genuine 12.04 and to repartition the way I wanted, did I reinstall from Precise std iso and upgraded to Trusty or install 14.04 from scratch, I can't remember : so this may be a left-behind file, or in second case maybe the magic installer of Trusty detected a certified make/model and added this ./trim ?

Whatever, am I right thinking my Dell won't trim twice a week ? Not that I'd be afraid, I even think to mv trim ../cron.daily. You'd just tell in another way that cron.weekly/fstrim just never ran a trim in this machine.

Ignoring this I bought a Samsung for my wife's old laptop ~ 2 years ago. Single script there in cron.weekly => no question.

Then last week I could put my hands on a secondhand Crucial M4 to which I cloned the old IDE that did the / for my desktop... there I guess trim will never run as long as I don't copy the trim script of the laptop or I don't add the intended parameter in the fstrim one. If I run

sudo /etc/cron.weekly/fstrim

echo $?


Strange isn't it?, Crucial not being white-listed and fstrim script being out-of-the-box unmodified. This maybe by script or sub-script design (no log nor output whatever thing or nothing is done). Right? Should I do it? if yes, it can't be by the single magic of "No more whitelist" as one says. Among the hundred of 3.13 kernel updates since Trusty born, do some now make the ~fstab discard~ way more advisable/reliable than cron one?


I use this this in 14.04 in place of what Ubuntu had in /etc/cron.weekly, noting I know my ssd handles trim (even though it was incorrectly blacklisted in 14.04 which never updated it's list to reflect newer drives or updated firmware on older drives.

echo "*** $(date -R) ***" >> $LOG
fstrim -v / >> $LOG

Once a week here is fine (- keep in mind the week starts on the the day you installed not Sun. or Mon per se

Log can be found in /var/log named trim.log

To check if ok without waiting for possibly a week run this

sudo run-parts /etc/cron.weekly -v

  • Yes man, this is exactly what I have in my Dell. This script is the exact one we find on webup8, so I also wandered if it could be added by Ubuntu-Tweak. About your remark on 14.04 never updated, I also wandered if this was a consequence of decision they did to use WL instead of a BL. BTW I copied it to my desktop. The single difference in this use-case is trim logs when fstrim doen't, isn't it ? Why did you use run-parts instead of simply ..../trim ? – useful Jul 22 '17 at 12:03
  • run-parts uses the script in cron just like it would be used by anacron to test the script. Doesn't do you any good if you don't put it in /etc/cron.weekly. The decision to blacklist ssd's in 14.04 was based on outdated info, track down the bug report to see comments. If you want to have this run by itself weekly than as mentioned place the script /etc/cron.weekly. Otherwise you can just run fstrim / command anytime you want. – doug Jul 22 '17 at 14:35
  • I did read the bug given in example in the man. It is there where I learned the BL, but I don't remember I read arguments pro/cons BL vs WL. I kept figuring them, even the decision to deal with the bugs at vendor level instead of make/model/firmware. – useful Jul 23 '17 at 17:56
  • Now I feel I have a bit more understanding, I steel wander why my log shows such a huge amount of trim every weeks since installation on fall 2013 : roughly the size of my SSD nearly each week, even I'm not a heavy video/music or any big files user. – useful Jul 23 '17 at 18:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.