Linux and TRIM

It hit me out of the blue that while using Linux with an SSD, is TRIM being utilized? After some digging it seems that it isn't! I had found an article that demonstrated how to setup a daily cron job to run TRIM on an SSD. But it seems that this particular article left out some details regarding process.

I was then introduced to this:

http://chmatse.github.io/SSDcronTRIM/

I have it installed as of yesterday. I will check the log files and see if its working!

What's the terminal output from the command cat /etc/fstab?

this is from my mint/ kde 16 pc:

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/sdb1 during installation
UUID=c4f88a66-0de1-4d7e-85d5-7ee17e84b9c3 / ext4 errors=remount-ro 0 1
# swap was on /dev/sdb5 during installation
UUID=d5655bf2-706e-4868-bdfc-3554e2bc9649 none swap sw 0 0


EDIT:

this is from my mint / kde laptop 14 that has the TRIM app running now:

/etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc nodev,noexec,nosuid 0 0
# / was on /dev/sda3 during installation
UUID=fed3b31b-80fc-4522-994e-ce5f02c743b4 / ext4 errors=remount-ro 0 1
# swap was on /dev/sda5 during installation
UUID=247267d1-e37f-45fa-95b6-e949eebe47b4 none swap sw 0 0

It's just a matter of adding discard to each of the ext4 UUID lines on both drives, separated by a comma...

ext4 discard,errors=remount-ro 0 1

I was reading about that, and one site said that using discard was slow and not recommended:

http://www.webupd8.org/2013/01/enable-trim-on-ssd-solid-state-drives.html

They recommended fstrim...

After discussing this with another user, they pointed me the application in my first post. Would you happen to know is the discard method is 'bad' in any way?

I wasn't aware of the fstrim method. It looks like that's the better route to take.

I am still a nooblet when it comes to linux... So much to learn!

Trim is implemented in newer versions of Ubuntu. I am pretty sure Arch has it as well. But i have also read that fstrim was the better way to go

I've been using ext4 with discard for almost 2 years with no problem. There is nothing innately slower about discard, unless you have some silly program installed that is vomiting up pointless sync calls every three milliseconds.

I have used discard for as long as I can remember with no issues.

I also add in noatime,nodiratime also after discard. That will turn off the needless writes for viewing a file or directory

Adding discard to the mount options will impose a small performance penalty, but, unless you're trying to squeeze every last bit of performance out of your SSDs: Not so much as you'd likely notice in regular use.

I'm simply going to run fstrim every night, during the wee hours, under a root cron job.

Jim

Maybe every couple of days or so... unless you beat on your drive a lot?

jseymour said:

Adding discard to the mount options will impose a small performance penalty

Click to expand...

Not really. Mounting without discard and then running fstrim later will just take all the time those small discards might've taken at once. If you run a database server with SSDs, you probably want to skip discard and run fstrim during a maintenance window, but on a home desktop, you probably want discard, to avoid having to set up a cron job (and leave the system on to get around to that cron job), or to avoid a delay during shutdown or startup.

fall said:

I also add in noatime,nodiratime also after discard. That will turn off the needless writes for viewing a file or directory

Click to expand...

No need to specify nodiratime separately. It is implied by noatime. Also, relatime has been default since Linux 2.6.30, so unless your system is rather outdated, there are no "needless writes for viewing a file or directory" in the first place.

I have no idea about linux and trim but most SSD have GC so even if trim isn't working they are performing self cleaning when drive is in idle state. For most SSD 30 mins is enough to clean all drive.

petteyg359 said:

Not really. Mounting without discard and then running fstrim later will just take all the time those small discards might've taken at once. If you run a database server with SSDs, you probably want to skip discard and run fstrim during a maintenance window,

Click to expand...

Didn't you just contradict yourself? I.e.: If discard didn't impose some small, but non-zero performance penalty, why would even database servers forego it?

petteyg359 said:

but on a home desktop, you probably want discard, to avoid having to set up a cron job (and leave the system on to get around to that cron job), or to avoid a delay during shutdown or startup.

Click to expand...

Unless your machine is (also) a server, you know what you're about and setting up a root cron job is second nature to you

But I think we're picking nits, here. Except for certain corner cases, I don't think it matters, much, one way or the other.

Woomack said:

I have no idea about linux and trim but most SSD have GC so even if trim isn't working they are performing self cleaning when drive is in idle state. For most SSD 30 mins is enough to clean all drive.

Click to expand...

Not the same thing. GC is merely the drive's way to recover unused space in a performance-efficient manner. Trim is a way for the OS to tell the drive what's unused.

To increase longevity: SSDs shuffle data around to even-out the wear on on the drive. Some argue failure to Trim will actually cause those shuffling algorithms to increase wear, rather than decrease it, by unnecessarily rewriting unused data blocks.

Jim

jseymour said:

Didn't you just contradict yourself? I.e.: If discard didn't impose some small, but non-zero performance penalty, why would even database servers forego it?

Click to expand...

Not at all. I said that the performance penalties are equal, but that one (discard) is spread into lots of tiny chunks of time, and the other (fstrim) is a single (relatively) large chunk of time, and maintenance windows provide nice large chunks of time to be used