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
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?