SSD Samsung 860 a 870 mají problémy v Linuxu

Na 500GB 870 EVO SATA jedu zhruba 5 měsíců. Mám na tom celý systém včetně swap partišny a celý /home, a to na Ext4. První den jsem na to nahrnul cca 300GB maximální rychlostí, od té doby odhaduji zápis v průměru zhruba v jednotkách GB denně. Volné místo se motá typicky někde lehce nad 50% kapacity celého SSD Nevím, jaké nastavení kernelu používá Mageia 8 a ani nevím, jaký problém bych měl pozorovat. První 3 měsíce Haswell, nyní Comet Lake.

Problém tam asi bude: "... But there is a large number of users which is still reporting issues with the Samsung 860 and 870 SSDs combined with Intel, ASmedia or Marvell SATA controllers and all reporters also report these problems going away when disabling queued trims."

Záleží, jak je TRIM používán? Jako discard v /etc/fstab? Nebo jenom jako týdně fstrim.timer? Nebo ani ten timer není aktivován?

Stejně bych raději pro jistotu ncqtrim zakázal.

Denní zápis bude kvůli logům a swapu někde jinde, celkově zapsaná data se dají zjistit přes smartmontools

@David Jezek: Z architektury CPU tazko zistit, ci mate zranitelny SATA radic. Pomohol by skor typ zakladnej dosky, idealne aj revizia (obcas sa s reviziou moze nejaka drobnost zmenit). Mozno mate radic, ktory v clanku nie je vymenovany a teda predpoklada sa 100% funkconst.

A nebo lspci :-)

njn, ono z Cometu tak trochu plyne i řadič, prostě Intel 400 či 500, ale abych tedy byl přesný:

00:17.0 SATA controller: Intel Corporation 400 Series Chipset Family SATA AHCI Controller (prog-if 01 [AHCI 1.0])
DeviceName: Onboard - SATA
Subsystem: Micro-Star International Co., Ltd. [MSI] Device 7c88
Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 123
Memory at a0328000 (32-bit, non-prefetchable) [size=8K]
Memory at a032c000 (32-bit, non-prefetchable) [size=256]
I/O ports at 5050 [size=8]
I/O ports at 5040 [size=4]
I/O ports at 5020 [size=32]
Memory at a032b000 (32-bit, non-prefetchable) [size=2K]
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [70] Power Management version 3
Capabilities: [a8] SATA HBA v1.0
Kernel driver in use: ahci


EDIT: jinak ty kernelový parametry z textu zprávičky Mageia u mě zjevně nenahazuje.

6. 9. 2021, 17:58 editováno autorem komentáře

Bych to viděl tak, že to je pořád tak rychlé, že to normální člověk nepozná.

To je pointa, kterou jsem chtěl naznačit. Prostě queued TRIM může být fajn, ale dá se bez něj žít. Ostatně mě vůbec nevadí, že mám SATA SSD, i když kdybych s nákupem počkal 3 měsíce, mohl jsem mít obdobné o malinko levněji s NVMe/M.2. Je to úplně jedno.

Možná jsem jen unavenej z práce, ale vůbec nevidím, jakou škodu to má způsobovat (ta chyba v SSD). Vidím jen, že jim to do logu píše WRITE FPDMA QUEUED a jinak nic.

Já mám přesně stejné SSD, které se probírá v tom bug reportu:

Device Model: Samsung SSD 860 EVO 500GB
Firmware Version: RVT01B6Q

ASMedia controler na AMD desce a jedu v této konfiguraci od roku 2019 a vše v pořádku (a v logu se chyba nevyskytuje). Kombinace FS ext4, xfs, btrfs. A fstrim.

Vlastně jsem na tom dost stejně jako tento uživatel. A v celém threadu není jediný potvrzený data loss.

Tak on to hezky shrnuje ten koment hned pod ním:

... problem is limited to "ATI AMD" AHCI controllers - 0x1002, not "Modern AMD" - 0x1022. ...

However, we are still disabling NCQ TRIM for Samsung SSD 840/850/860/870 on all controllers, but this is expected to have neglectable perf impact.

Jo, zrovna jsem na to natrefil taky.

However, we are still disabling NCQ TRIM for Samsung SSD 840/850/860/870 on all controllers, but this is expected to have neglectable perf impact.

Dokud nevypnout i NCQ jako celé, tak je to jedno.

For clarification - we established in https://bugzilla.kernel.org/show_bug.cgi?id=201693 that the problem is limited to "ATI AMD" AHCI controllers - 0x1002, not "Modern AMD" - 0x1022.

Aha, tak tím se to vysvětluje. Na desce z roku 2017 mám ten "modern" řadič.

Jsem za zavedeni CONFIG_MIDDLEFINGER aby tyhle zarizeni nebyly podporovany degradujicimi workaroundy a kernel pred spustenim initu zobrazil vyrazne varovani ve stylu pomnicku z prostrednicku a udrzenim minuty ticha pro vase rozbite periferie. Pak se muze bootovat dal.

Nechapu totiz postoj Samsungu, ktery neni schopen bug vyresit a replikuje ho uz temer cele desetileti.

To není doménou Samsungu, dělají to tak všechny korporace. Než dělat HW revizi (další SKU, revize všech navazujících BOMů, marketing, informování distributorů, ...) tak se udělá softwarový workaround, protože u softwaru nikdo formálně neřeší spolehlivost nebo odpovědnost, prostě se očekává, že to nebude fungovat perfektně a že se kdyžtak stahne update nebo se to nějak okecá.

Nemusí být ani softwarová záplata, když se to daří hasit pomocí PR. Díky tomu např. Apple mohl mít na 3 generacích Airu lámající se flex kabel k displayi a tvrdit, že není problém. Až v MY 2020 ho prodloužili o pár mm, a zázrakem se jim už netrhá při opakovaném plném otevření displaye.