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.
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
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.
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.