SSD trouble

One of my PCs has a 60.0 GB Corsair Force GT SandForce Driven SSD. When I bought it, I read a bit about SSDs and I set several options in my /etc/fstab. However, whenever copying some big files, the system seemed to hang for a while. In other cases, the it would just crash, killing X and leaving me in the console, but even shutting down was not possible. It would spit out errors, containing stuff like:

EXT4-fs error ... ext4_find_entry ... unable to read itable block

I searched a bit and found that either my filesystem was corrupted or that my disk was dying. I decided to dig into the first possibility, before I decide to go and buy a new disk. If there was a problem with the filesystem, may be the mount options I had specified were not the best choice. This is how the root partition had been mounted in my /etc/fstab:

/dev/sda2   /   ext4  defaults,noatime,discard   1   1

Reading the Gentoo wiki, was indeed educational. They advise against using the discard option, as it could potentially cause performance degradation on older SSDs:

The -odiscard option on a rootfs mount should not be used. discard is the “TRIM” command that tells the SSD to do its magic. Having discard running constantly could potentially cause performance degradation on older SSDs.

Instead, they suggest that the TRIM command be run manually:

fstrim -v /

or as a cron job.

The Arch Linux wiki has an excellent article on SSD. They also warn against enabling continuous TRIM by mount flag:

Users need to be certain that their SSD supports TRIM before attempting to mount a partition with the discard flag. Data loss can occur otherwise! Unfortunately, there are wide quality gaps of SSD’s bios’ to perform continuous TRIM, which is also why using the discard mount flag is recommended against generally by filesystem developer Theodore Ts’o. If in doubt about your hardware, #Apply periodic TRIM via fstrim instead. Also be aware of other shortcomings, most importantly that “TRIM commands have been linked to serious data corruption in several devices, most notably Samsung 8* series.” After the data corruption had been confirmed, the Linux kernel blacklisted queued TRIM command execution for a number of popular devices as of July 1, 2015. Read Samsung Finds, Fixes Bug In Linux Trim Code on Slashdot for more recent updates.

The Arch Linux wiki also suggests applying periodic TRIM by fstrim, but their instructions are systemd specific.

So, as a conclusion — the discard option may cause problems with some hardware, especially when used for the root filesystem.

The other option I had specified in my /etc/fstab was noatime. The Arch Linux wiki notes that issues may occur with some programs and suggests using relatime, instead:

Using the relatime option instead of noatime will ensure that the atime field will never be prior to the last modification time of a file.

In fact, the Gentoo wiki suggests relatime by default in their /etc/fstab example configurations.

I ended up reformatting the whole SSD and making a clean install of Slackware. I chose XFS without changing the default settings. I may do this after I read some more. The system has been working very well for a week.

Was it really just misconfiguration? This old SSD post of mine describes my /etc/fstab settings, that were apparently not good. I chose them following the Arch wiki, but I do not remember if all those warnings were present at the time. Later, there was this discussion at LQ and several users also recommended the noatime and discard options. Actually, I also posted a reply, asking others if these options were safe. Apparently not, at least for my SSD (provided this was a software problem and not a hardware failure)!

So, what is the moral of this story? The Disclaimer page is here for a reason!

---