Samsung 860/870 SSDs Continue Causing Problems For Linux Users

[castlefox]

Well this is great timing on part. I have an first gen Ryzen system and over weekend I upgraded to a NVMe drive and removed my Samsung 870 SSD (so that my PS5 could use it).

[torsionbar28]

So basically this only matters if you insist on using continuous TRIM or have an ATI controller. Most could/should just do the weekly TRIM with fstrim.timer instead in which case queuing doesn't matter all that much. If you do have an ATI controller you will be without TRIM all together, which reportedly could have some performance implications. But, otherwise, saying "Linux users are best off just trying to avoid the Samsung 860 and Samsung 870 series drives" is a bit of an exaggeration.

I thought the fstrim.timer has always been the recommended method on Linux? I remember reading a while back that continuous trim was both slower in day to day use, and caused more wear to the SSD cells, so it was advised not to use it. Seems that advice holds up.

[brianstamper]

I thought the fstrim.timer has always been the recommended method on Linux? I remember reading a while back that continuous trim was both slower in day to day use, and caused more wear to the SSD cells, so it was advised not to use it. Seems that advice holds up.

Yeah in the discussion here and elsewhere on this I haven't heard anyone who is for using continuous, and it sounds like it is or will be the default for many distros. So that is the first reason this might not matter for most people. As for the ATI thing (for those that might not know this), do:

sudo lspci -v | less

And look for the section for your SATA controller. If the Subsystem line is not "ATI" then that is also not an issue for you, in which case this doesn't matter at all, enjoy your perfectly functional SSD.

[Brisse]

Edit: Nevermind. I'm using LVM+LUKS and it turns out it's more complicated to set up TRIM on a system like this. Also, it's disabled in cryptsetup by default for security reasons. I did manage to do it though, and successfully TRIM'ed the device.

---

Quick question to those of you with more in depth knowledge on this, as I'm honestly a bit confused.

I have a Samsung SSD 850 EVO 500GB (EMT02B6Q) hooked up to:

01:00.1 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD] X370 Series Chipset SATA Controller [1022:43b5] (rev 02)

I'm running Debian testing. Continued TRIM as well as fstrim.timer seems to be disabled.

I tried to manually invoke 'fstrim -a -n -v' and then 'fstrim -a -v' (after making a fresh backup) like another user did in a previous post in this thread, but unlike that user, fstrim doesn't return anything at all.

kristoffer@debian-desktop:~$ sudo fstrim -a -n -v
[sudo] lösenord för kristoffer:
kristoffer@debian-desktop:~$ sudo fstrim -A -n -v
kristoffer@debian-desktop:~$ man fstrim
kristoffer@debian-desktop:~$ sudo fstrim -A -v
kristoffer@debian-desktop:~$ sudo fstrim -a -v
kristoffer@debian-desktop:~$

Nothing! Is this because the kernel blocks TRIM on my particular setup?

I have noticed sometimes when for example I install a big ~50GiB game or whatever, that the desktop can freeze for a couple of seconds. Is this because my SSD isn't TRIM'ed?

[PeterB]

Seeing lots of mention to SATA here. Are NVMe drives unaffected?

[Svyatko]

What would be a linux friendly drive manufacturor ?

Those with Phison controller.
Works OK with ATI chipset where Samsung 860 Evo fails.
Can use Samsung, but with NCQ disabled => reduced speed.
ILL all AMD/ATI pre-AM4 chipsets have these troubles. For desktop you may use PCIe SATA controller, but for laptop - not.
To find errors: check dmesg output for red letters.

[Svyatko]

Seeing lots of mention to SATA here. Are NVMe drives unaffected?

Unaffected with these particular issues. You may get troubles with using NVMe SSDs on older chipsets with PCIe 1.0 or 2.0.
Users report about incompatibility with some old Intel chipsets + some WD NVMe SSDs.

[Svyatko]

This is a pity, as Samsung has traditionally been one of the better SSD makers, or at least the most recommended. I used to use Plextor's SSDs (though I suspect they are rebadges of someone elses drives), but I've used Samsung drives in a couple of builds so far and been happy with them.

IMHO Samsung SSDs are over-hyped.
Plextor develops SSDs by its own engineer team. Previously with Marvel controllers, now with ex-Marvel employees firm InnoGrit.
I hope Plextor will work further and produce good goods.

[Svyatko]

So basically this only matters if you insist on using continuous TRIM or have an ATI controller. Most could/should just do the weekly TRIM with fstrim.timer instead in which case queuing doesn't matter all that much. If you do have an ATI controller you will be without TRIM all together, which reportedly could have some performance implications. But, otherwise, saying "Linux users are best off just trying to avoid the Samsung 860 and Samsung 870 series drives" is a bit of an exaggeration.

Samsung has long list of errors - see https://github.com/torvalds/linux/bl.../libata-core.c
and https://github.com/torvalds/linux/co...7dd7293334ac49

With pre-AM4 chipsets users have to disable NCQ with different Samsung SATA drives => greatly reduce speed.
Saying "Linux users are best off just trying to avoid Samsung SATA drives" is a good advice from experienced user.

[Toster256]

Interesting article. I'm using 850 EVO with 5.8 years uptime and 860 QVO - 2.1 years. Last 3 years I have ZFS with autotrim enabled. No issues detected so far on various intel chipsets. I would probably notice data corruption and freezes and dmesg logs. Thus question, queued trim - is this the only way to do background triming or there is another way in ncq? Is there a way to disable this quirk using kernel command line arguments?