Ubuntu 14.10 onwards
In Ubuntu 14.10 and 15.04, TRIMming happens automatically every week on all SSDs supported by fstrim
.
$ tail -n1 /etc/cron.weekly/fstrim
/sbin/fstrim --all || true
Since 15.04 Ubuntu uses systemd and its timer (man systemd.timer
, Arch wiki)
systemctl list-timers
systemctl status fstrim.timer
Ubuntu 14.04
As of Ubuntu 14.04, scheduled TRIM is enabled by default for Intel, SAMSUNG, OCZ, Patriot and Sandisk SSDs. If you have another brand, you could disable the vendor check by running the following command:
sed -i 's/exec fstrim-all/exec fstrim-all --no-model-check/g' /etc/cron.weekly/fstrim
(or just edit the file /etc/cron.weekly/fstrim
and add --no-model-check
)
Ubuntu 13.10 and Earlier
There are three ways to perform TRIM, manual, scheduled, and automatic:
Manual TRIM
In Ubuntu this can be performed with fstrim
:
sudo fstrim /
however it is not needed when scheduled or automatic TRIM are enabled, as detailed in the sections below.
Note: For Ubuntu 11.04 and earlier systems, fstrim is not available so you have to use wiper.sh
supplied with hdparm
in /usr/share/doc/hdparm/contrib/wiper.sh.gz
Scheduled TRIM (Recommended)
This is the currently recomended method, and is planed to be activated per default for Ubuntu 14.04. Here's how to activate it manually in older versions of ubuntu (11.10 to 13.10):
Create a weekly CRON job script file:
gksudo gedit /etc/cron.weekly/fstrim
Paste the following code in the file, then save and close the file:
#! /bin/sh
# By default we assume only / is on an SSD.
# You can add more SSD mount points, separated by spaces.
# Make sure all mount points are within the quotes. For example:
# SSD_MOUNT_POINTS='/ /boot /home /media/my_other_ssd'
SSD_MOUNT_POINTS='/'
for mount_point in $SSD_MOUNT_POINTS
do
fstrim $mount_point
done
Note that the above assumes that only your root filesystem /
is located on an SSD. If you have more mount points that reside on one or more SSDs, add them to SSD_MOUNT_POINTS
as explained in the code.
Make the script executable:
sudo chmod +x /etc/cron.weekly/fstrim
And finally test it:
sudo /etc/cron.weekly/fstrim
If you see no errors, your cron job should be working fine.
Automatic TRIM (Deprecated, Slow)
Automatic TRIM has been supported since Ubuntu 10.10 (kernel 2.6.33) with the EXT4 file system. However, sending TRIM commands to the SSD in real-time - after every delete - has been recognized to make deletion much slower than usual on some drives. Therefore a weekly scheduled TRIM via a cron job (described above) is recomended.
To enable automatic TRIM on a drive or partition, they need to be mounted with the discard
option in fstab
. Firstly backup your fstab then open it for editing:
sudo cp /etc/fstab ~/fstab-backup
gksudo gedit /etc/fstab
Add discard
to the fstab options entry (comma separated) for the SSD drive or each partition.
UUID=00000000-0000-0000-0000-000000000000 / ext4 discard,errors=remount-ro 0 1
Close and save fstab, then reboot and automatic TRIM should now be working.
Testing automatic TRIM
To test if TRIM is working issue the following commands (source):
cd / # Replace with SSD file system
sudo dd if=/dev/urandom of=tempfile count=100 bs=512k oflag=direct
sudo hdparm --fibmap tempfile
From the output copy the number under begin_LBA
and verify the device name of your SSD: System->Administration->Disk Utility
e.g. sda, sdb, sdc ...
Run the following but replace [ADDRESS]
(begin_LBA) and sdX
(SSD device name) with the details obtained above.
sudo hdparm --read-sector [ADDRESS] /dev/sdX
the output should be a long string of characters for those sectors
sudo rm tempfile
sync
Repeat the hdparm
command from above:
sudo hdparm --read-sector [ADDRESS] /dev/sdX
If you get only zeros then automatic TRIM is working. However if after removing the file the sectors are still not empty then wait a while and run the command again.
The difference between automatic and manual trim is that automatic trim (using the discard
mount option) trims freed blocks on sync after any file is deleted, whereas manual trim (using fstrim
) trims all the free space at once.
Testing
One way you could test whether automatic trim is working would be to create and delete a large file:
user@host:/somewhere$ dd if=/dev/urandom bs=1M count=100 of=bigfile
user@host:/somewhere$ sync
user@host:/somewhere$ rm bigfile
user@host:/somewhere$ sync
If automatic discard is working, manually trimming again won't trim many blocks, since they should have already been trimmed. Run sudo discard -v
on your filesystem and see how many blocks are trimmed.
Recommendation
As for which is recommended: In my experience, automatic trim kills performance. However, this is probably hardware-dependent; it may be fine on your drive.
If you're using manual trim, as for how often, think about the rate at which you write data in your typical workload, compared to the amount of free space on your SSD. You want to trim sufficiently often, before your disk fills up with deleted data. If your SSD is mostly free space or your disk workload is light, trimming occasionally (weekly or even longer) should suffice. If your SSD is mostly full or you e.g. edit video files frequently, you'll need to trim more often.
Best Answer
Short answer: to your question on the effect of disabling TRIM in Trim ready SSDs, I would not do it.
Long answer: here's why:
Loosely quoting from an earlier post:
TRIM prepares at-least-once written physical blocks on an SSD for new write operations (Wop's), obviating the need to actually erase the targeted blocks immediately before the Wop occurs (as would be the case in a setup w/o TRIM). For that the SSD must have a hardware controller that is TRIM-ready. It is not always the case.
In a first phase of use is, i.e. when the brand new SSD has just been installed and is still relatively new, all the SSD blocks have not yet been written over at least once. During that phase TRIM does not kick in systematically and brings limited benefit to the overall r/w speed.
After that early phase, which depends on a number of factors, among them how much you write・access the SSD, Wop's will slown down to reach a speed plateau.
At that stage, a rule of thumb is that TRIM more than halves write-times on TRIM-ready SSDs with respect to the same hardware without TRIM enabled. Some maintain that the regular use of
fstrim
, the garbage-collection utility that actually carries out the zero-rewrite on already once written but now discarded blocks, will boost your write-speed by a factor of 4 (yes, 400%!) or more. I (and most people) have no way of controlling that, short of isolating and looking at blocks being written with and withoutfstrim
's garbage collection at work.HTH, at least conceptually. To know more you will have to delve in a number of rather technical white papers. They get seriously abstruse to the non-expert.
On the matter of disabling TRIM, first check that your SSD IS TRIM ready and TRIM is enabled:
CAUTION: read your man page on
hdparm
before using it. You can thoroughly corrupt your system in case of misuse. The command above is completely harmless though.If you get a blank then TRIM is not enabled -> case closed
If you get
* Data Set Management TRIM supported (limit 8 blocks)
then check that TRIM is actually active on your machine.On Ubuntu, there are two possibilities (known to me):
you may have a
discard
as mount option in your /etc/fstab file, for any SSD device typically formatted as either ext3 or ext4. In case your mounted volume has the ext3 format, thediscard
mount option is known to actually constrain the volume to be read-only. That would get anybody's attention rather rapidly I think. So chances are any volume with thediscard
mount option will be ext4.you can program
fstrim
to run automatically on a regular basis (hourly, daily, weekly or otherwise). To check that you havefstrim
so programmed, enter the following in terminal:$ find /etc/ trim | egrep fstrim
At least on Ubuntu 14.04.x, which is what I run these days,
fstrim
is scheduled to kick in once a week, which is about right for any normal desktop user. You might want to go up to a daily frequency if you run a data write-intensive services, i.e. a performance oriented database management system. WADR, somehow, if you had to ask, I doubt it is the case.Finally, yes, suppressing
fstrim
or removing it from its/etc/cron.{hourly,daily,weekly,monthly}
directory will stop the trimming process on your machine.My opinion (provided at your request and not as a recommendation you should necessarily follow): You are probably safe leaving that
fstrim
file where it is. If you prefer disabling it, go and buy an equivalent conventional disc based (HDD) drive to replace it. You might be better off than with an SSD with no TRIM activated, having paid a premium for it. But frankly using your extracted SSD as a paper-press would be a pity. That would be taking thediscard
option for TRIM garbage collection quite literally.