[Solved] TRIM support for SSD drives?

Archived topics about LMDE 1
Locked
HilltopsGM
Level 4
Level 4
Posts: 201
Joined: Thu Mar 15, 2012 8:11 pm

[Solved] TRIM support for SSD drives?

Post by HilltopsGM » Thu Apr 03, 2014 4:32 am

Apparently Mint 17 is supposed to come with Automatic Trim support for SSD's.

Does (Will?) LMDE have TRIM support SSD support? with the 201403 Release?

Thanks
Last edited by HilltopsGM on Sun Apr 06, 2014 6:53 pm, edited 1 time in total.

User avatar
eanfrid
Level 7
Level 7
Posts: 1859
Joined: Mon Apr 30, 2012 2:49 am
Location: FR

Re: TRIM support for SSD drives?

Post by eanfrid » Thu Apr 03, 2014 5:11 am

The TRIM functions are fully supported since the last 2.6 kernels for all file systems able to deal with them. You have two ways to enable this:

1/ mounting the volume with the "discard" option (old way, not recommended)
or
2/ using a cron job to run periodically the "fstrim" command on chosen volumes (at least once a week)
Main desktop: Debian GNU/Linux Jessie 64bit - MATE
(i5 2400@3.7GHz - 16GB DDR3 - HD6770 w/radeon driver - SSD+RAID1)
Safer than Dropbox

HilltopsGM
Level 4
Level 4
Posts: 201
Joined: Thu Mar 15, 2012 8:11 pm

Re: TRIM support for SSD drives?

Post by HilltopsGM » Thu Apr 03, 2014 10:16 pm

Will TRIM support be managed automatically at some point in time in the future?
Is there a road map for this?
I was just curious what the time frame might look like for that.

Not that this has any bearing on what LMDE does, but if Mint 17 is going to have it automated, is there going to be something like that for LMDE?

As a side question, if TRIM functionality is running, how much will that impact the the systems usability if you try to use it while running email, spreadsheets, & browsing the web?
Any idea?
(it is not a old machine - brand new, mid grade components - AMD A-8 6600 processor, 8 GB of RAM)

Thanks

User avatar
eanfrid
Level 7
Level 7
Posts: 1859
Joined: Mon Apr 30, 2012 2:49 am
Location: FR

Re: TRIM support for SSD drives?

Post by eanfrid » Fri Apr 04, 2014 1:51 am

At the present time, TRIM is only automated for swap partitions. Regarding other file systems, the "discard" option is one of the many mount options of a volume and IMO should stay as is since you may want not to automatically use TRIM. It looks like Ubuntu chose one of the best solutions (no "discard" and a weekly cron job, run when the system is most probably idle). LMDE mainly depends on Debian, so unless the Mint devs add some tweaking, there will probably be no TRIM automation in LMDE before a while.

Whatever the performance of you cpu/ram is, TRIM functions trigger only "disk" i/o intensive tasks. If TRIM functions are triggered while you do some other disk i/o intensive task (read or write), all SSD operations will be dramatically slowed down for maybe a few minutes. So TRIM operations get out of the way and are best used when your system is really idle (hence the "cron job solution" or generally speaking an "on-demand" run).
Main desktop: Debian GNU/Linux Jessie 64bit - MATE
(i5 2400@3.7GHz - 16GB DDR3 - HD6770 w/radeon driver - SSD+RAID1)
Safer than Dropbox

mintybits
Level 6
Level 6
Posts: 1123
Joined: Fri Jan 27, 2012 5:09 pm

Re: TRIM support for SSD drives?

Post by mintybits » Fri Apr 04, 2014 3:42 am

eanfrid wrote:The TRIM functions are fully supported since the last 2.6 kernels for all file systems able to deal with them. You have two ways to enable this:

1/ mounting the volume with the "discard" option (old way, not recommended)
or
2/ using a cron job to run periodically the "fstrim" command on chosen volumes (at least once a week)
Why do you say discard is not recommended? Disagrees with this: https://wiki.archlinux.org/index.php/Solid_State_Drives
It is simpler to add discard to fstab.
In this regard Linux is sort of in the Stone Age and ought to do all this automatically without user intervention. :?

User avatar
eanfrid
Level 7
Level 7
Posts: 1859
Joined: Mon Apr 30, 2012 2:49 am
Location: FR

Re: TRIM support for SSD drives?

Post by eanfrid » Fri Apr 04, 2014 4:14 am

TRIM is not as so simple as you may think it is. And unless you own a very recent MB and SSD supporting both at least SATA 3.1, "discard" (automatic trimming) is worse for SSD performance than scheduled/on-demand trimming:

https://en.wikipedia.org/wiki/Trim_%28c ... ortcomings ... (also, Linux supported SSD trimming before any other OS did :) )
http://askubuntu.com/questions/205930/a ... anual-trim
and many more with some googling

Even with SATA 3.1, it has yet to be reported if the new SATA queued trim commands really solve the problem (compared to scheduled trimming).
Main desktop: Debian GNU/Linux Jessie 64bit - MATE
(i5 2400@3.7GHz - 16GB DDR3 - HD6770 w/radeon driver - SSD+RAID1)
Safer than Dropbox

HilltopsGM
Level 4
Level 4
Posts: 201
Joined: Thu Mar 15, 2012 8:11 pm

Re: TRIM support for SSD drives?

Post by HilltopsGM » Sun Apr 06, 2014 6:40 pm

Hey folks,

I have been testing out the code

Code: Select all

sudo -v fstrim /
and
sudo -v fstrim /home
It seems to Trim very quickly.
Rather than run a 'Weekly' cron, would it not be a good idea to run it on startup?

Like I said, it seems to happen in a matter of 10sec or less on the 20GB and 80GB partitions that I have, and it takes me longer than that to get started once I have the machine started :lol:

Frequent Trimming shouldn't cause any undo wear should it?

Comments?

HilltopsGM
Level 4
Level 4
Posts: 201
Joined: Thu Mar 15, 2012 8:11 pm

Re: TRIM support for SSD drives?

Post by HilltopsGM » Sun Apr 06, 2014 6:53 pm

hmmm, disregard that last post.

http://koitsu.wordpress.com/2013/02/12/ ... ure-works/

From that page, this sums it up pretty good:
I cannot stress this point enough. In fact, depending on the behaviour of the TRIM implementation (see above), this could actually cause excessive wear/tear on the NAND flash if done repeatedly. Which leads me to…
It looks like it is not a black and white answer.
It sounds like it really depends on the SSD manufacturer and what exactly the operation that is being performed during "TRIM" operations.

Setting up the Cron sounds good enough for me.

Locked

Return to “LMDE 1 Archive”