1

I read the following article on a problem with TRIM and Samsumg.

I am running Ubuntu 14.04.1 and I have a Samsung PRO 850 of 250GB.

I am worried to get my file system damaged due to same firmware problem.

Does anybody have issues with same SSD and Ubuntu version?

Do you suggest to disable trim for safety?

If yes, it is enough to delete the file /etc/cron.weekly/fstrim ?

Thank you, Simone

  • This are three questions. – A.B. Jun 19 '15 at 19:22
  • I would suggest editing yr question and supressing the polling question "does anybody have issues with...". – Cbhihe Jun 20 '15 at 19:18
  • would be nice to have some feedback on answer(s) brought to you. At least a simple aknowledgment. – Cbhihe Jun 24 '15 at 12:20
  • Hi Cbhihe, thank you for explanation. I have trim enabled and I kept it running as per your suggestion. I had no problem up to now with file system corruption. I do not want to age sooner my SSD. Thank you Simone – Simone Pernice Jun 24 '15 at 12:57
2

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 without fstrim '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:

$ sudo hdparm -I /dev/sda | grep "TRIM supported"

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, the discard 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 the discard 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 have fstrim 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 the discard option for TRIM garbage collection quite literally.

  • Hi Cbhihe, thank you for explanation. I have trim enabled and I kept it running as per your suggestion. I had no problem up to now with file system corruption. I do not want to age sooner my SSD. Thank you Simone – Simone Pernice Jun 24 '15 at 12:59
  • A well made SSD will work fine without discard or TRIM even in long run. If your SSD manufacturer is Intel or Samsung, it may be a well made SSD. An SSD drive made by any other manufacturer will require discard and TRIM to work in long run. And even then, the changes are it will behave badly if you ever fill it. – Mikko Rantalainen Oct 2 '17 at 11:51
0

after Samsung investigation the problem was due to a bug on Linux Kernel on raid. It looks like there is a misunderstanding between raid driver and scsi/ata driver.

You can find the detail in the following link raid0: data corruption when using trim .

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.