Folytatódik a Linux felhasználók kálváriája a Samsung 860/870 SSD-kel

Címkék
[...] 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. Note that with AMD SATA controllers users are reporting even worse issues and only completely disabling NCQ helps there [...]
Részletek itt. Blacklist commit itt.

Hozzászólások

Szerkesztve: 2021. 09. 05., v – 12:28

luks miatt nem hasznalok discardot, de amugy mit kellene tapasztalni?

eleg ha az fstab-ban nincs discard, vagy az fstrim automatikus futasat is meg kellene akadalyozni?

neked aztan fura humorod van...

A lentebb linkelt bugreport szerint az fstrim is beakaszthatja ugy 30-30 masodpercekre az SSD vezerlot es kozben kopi az errorokat dmesgbe. Szerintem azon is sok mulik, hogy a trim futasa kozben egyeb diszk muvelet altalaban tortenik-e. A queued trim abban jelent kulonbseget a sima trim-hez kepest, hogy konkurensen tud kozben mas IO muvelet is futni ugyanazon a drive-on. Vagyis egy nagyobb torles (ha be van kapcsolva azonnali discard) vagy cronbol utemezett fstrim (ha eppen az van konfigolva) nem "fogja meg" percekig az SSD-t.

Régóta vágyok én, az androidok mezonkincsére már!

Nem kell megakadályozni semmit. A TRIM nem hajtódik végre, hacsak a LUKS rétegén kifejezett konfigurációval nem engeded át.

Egyébként meg sokan félreértik ezeket a problémákat. A szóban forgó problémás meghajtókon és vezérlőkön is működik a TRIM, a discard mount paraméter által használt folyamatos, és az fstrim által használt időszakos TRIM is megy. Csak ezeken a meghajtókon a queued TRIM adatvesztést okozhat, ezért a kernel feketelistázza, és a TRIM így is fog működni, de nem queued jelleggel, hanem a SATA driver kényszerítetten, soron kívül, azonnal végrehajtja, és nem teszi el később műveletekkel való sorbaállításra, azokkal nem kötegeli össze, hogy majd egy későbbi, még alkalmasabb időben, teljesítményre nézve optimálisabb időzítéssel legyen megoldva. Ennek viszont az a hátránya, ha egyszerre megszalad a TRIM-elni való, és azonnal ki van kényszerítve, akkor meg az lassulásokat okozhat I/O műveleteknél, ez is főleg akkor gond, ha valaki folyamatos discard-ot használ, ami a normál fájlműveletekkel van egybekötve. Ezért a legtöbb disztró átállt az fstrim használatára inkább, ez az ajánlottabb, de ez nem jelenti azt, hogy a discard-ot nem szabad használni, hanem hogy belassulásokat okozhat, de vannak fájlrendszertípusok, amiknél az embernek nincs választása, mert a discard támogatja ezeket, az fstrim meg igen pl. NTFS, régen voltak más fájlrendszerek, amik meg fordítva működtek (XFS, F2FS), de mára ezek száma lecsökkent, általában minden TRIM megoldás támogatni szokta őket Linux alatt.

A másik, hogy ez a TRIM probléma nem a Linux hibája. Konkréten a szóban forgó meghajtók TRIM teljesítménye Windows alatt is problémás lehet, mivel a gond firmware/hardver szinten leledzik. Illetve a TRIM támogatása önmagában is problémás, több OS-en, több fájlrendszertípussal is, pl. XP és korábbi verziók nem támogatják, OpenBSD, NetBSD nem támogatja, FreeBSD csak FFS1 partíciókon talán, ZFS-sel nem tudom mi a helyzet, MacOS csak a saját fájlrendszerein, és ott is állítólag számolnak be userek, hogy trükközni kell, ha azt akarja az ember, hogy az Apple által hivatalosan nem támogatott, 3rd party SSD-vel is menjen. Nem szokott tovább működni a TRIM sok esetben külső SSD-ken, ez is megint függ a külső meghajtóinterface chipjétől, annak driverétől. Problémás továbbá egész lemezes szoftveres titkosításnál, mivel ezen a TRIM-et átengedve adamintázati támadás valósítható meg, ha meg az ember nem engedélyezi a TRIM-et, akkor meg viszont az SSD élettartama csökkenhet, vagy az SSD belassulhat.

Mert az is igaz, hogy az SSD-kbe épített garbage collection is tudja valamennyire pótolni a TRIM hiányát, így a modern SSD-k ellehetnek TRIM nélkül, de az egész lemezes szoftveres titkosítás azért speciális eset, mert akkor az SSD vezérlője úgy látja, hogy az egész meghajtó tele van hasznos adattal, és nem lesz szabad helye, hogy a garbage collection pakolgassa rajta az adatokat.

Az se közismert, hogy ez az egész TRIM csak ATA, AHCI protokollt használó SSD-knél, illetve SCSI protokollt használóknál fontos (SAS, USB UASP, ezeknél UNMAP-nak hívják az utasítást, de ugyanazt csinálja). Ezek ugyanis még anno HDD-khez és egyéb hagyományos mechanikus meghajtókhoz lettek kitalálva, és az SSD-k támogatás csak utángondolás. NVMe-nél már úgy van megoldva, hogy a TRIM funkcióját elvégző utasítás ilyen atomi részműveletként már protokoll szinten be van építve más lemezkezelő utasításokba, így az OS-nek nem kell külön szoftveresen támogatni, meg külön hívogatni, meg a usernek bármit is állítgatni. Ez persze jó, de vannak hátrányai: előbb említett egész lemezes szoftveres titkosítás (a hardveres nem baj, mert az az SSD vezérlője transzparensen saját hatáskörben megoldja), meg esetleg véletlen TRIM-elt adatokat nem lehet visszaállítani, pl. ha NVMe-ről valaki véletlen töröl valamit, és végrehajtódik a TRIM-nek megfelelő részparancs is, akkor nem gondolhatja meg magát, hogy ó, bocs, nem akarta mégse törölni, se undelete, mindenféle adatmentő csodaszoftverek, se a Kürt nem hozza vissza az adatokat, mert a TRIM-nek megfelelő részművelet alapállapotba hozta az illető cellákat, amikben az adatok voltak és azok visszaállíthatatlanul törlődtek.

Igazából ez az egész TRIM egy komolytalan oroszrulett. Megy, ha megy, ha épp az OS, a driver, a firmware, a fájlrendszer támogatja, és épp nem fut bugba, és nem gyengíti a szoftveres titkosítást, és a RAID, LUKS, LVM. USB UASP rétegén is át van engedve, a user is engedélyezte és varázspálcával ráolvasott, valamit a csillagok és bárányfelhők is épp így állnak az égbolton, akkor és csakis akkor mehet, de még ilyenkor sem ismert, hogy egyes gyártóknál a firmware szintű garbage collectionnel milyen viszonylatban áll, mennyire védi a meghajtót, mennyire optimalizálja a teljesítményét. Nem kis részben a fejlesztők hibája is, hogy az SSD-k már 13 éve jelen vannak, terjednek a konzumer és céges szegmensben, és ez az idő nem volt elég arra, hogy az egyes OS-eknek, fájlrendszereken, interface-eken (NVMe kivételével) megoldják úgy a támogatását, hogy out of the box menjen, és ne a usernek kelljen az állítgatásával, bugokkal, stb. szívni, meg hogy ez se, meg az se, és amaz se támogatja. Nem kis szégyen és lustaság. Még régen, az SSD-k ősidejében jöttek sokan olyan szöveggel, hogy az SSD-k megbízhatatlanok, nem bírnak sok írást, TRIM-es technikai hókuszpókusz, drága, ők ilyen szarra nem költenek, inkább maradnak a hagyományos HDD-knél, de most már 10+ éve terjedve egyre olcsóbbak, néha a kisebbek már pendrive árában mennek, mindenkinek van, és a szoftver támogatás még mindig nincs megoldva hozzájuk. Mennyi idő kell még a fejlesztőknek, mire ezen a téren is összeszedik magukat, 50 év? Lehet arra várnak, hogy a JS frameworkök, meg a Python támogatni kezdje, vagy mi?

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Ááá, még közel sem, mert utólag jutott eszembe pl. hogy Windowson ez azért nem probléma, mert abban nincs NCQ TRIM, se folyamatos TRIM, csak időszakos (fstrim-nek megfelelő megoldás, hetente vagy havonta beütemezve). Bár még az se tudott, hogy pontosan mely OS-ek támogatják. De valóban, ha rövidebbek akarunk lenni, akkor annyi elég, hogy az egész SSD, TRIM témája egy nagy katyvasz. Aki ezt el akarja kerülni, vegyen NVMe-t, vagy használjon HDD-ket. Akinek meg Samsung 8xx-es SSD-je van, az lehetőleg ne használjon discardot, vagy csak úgy, hogy az NCQ TRIM-et kikapcsolja, szerintem azt valami kernelparaméterrel lehet elérni.

Nekem az egyik laposban van egyébként egy 500 gigás mSATA Samsung 860 EVO. Futott rajta Arch Linux egy ideig, de nem volt gondom vele, az is igaz, hogy nem discardot használok, hanem fstrim-et, de megfelelően működött minden, nem lassult be, nem lagolt, kernel hibát nem dobott, fájlrendszer konzisztenciájával sem volt gond. Firmware-rel sem volt sose problémám, pedig frissítettem rajta azt is. Jelenleg egy jó másfél éve be nem bootolt Windows 10 tesztrendszer van rajta, és 1-2 hét múlva megy rá egy FreeBSD, majd meglátom, hogy azon lesz-e probléma vele.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Ezt most nem értem. A firmwarefrissítő parancs az NVMe protokoll része, Linuxon egyszerűen az nvme utasítással shellből meghívva frissíthető a firmware (az ne zavarjon meg senkit, hogy „download” van a nevében, ettől még frissíteni is lehet vele, nem csak meglévő firmware-t lementeni, ez nem csak NVMe-nél, hanem sok nem SSD-khez kötőtő firmwarefrissítő szoftverben is gyakran download-nak van nevezve), semmilyen spéci progi meg bootakármi nem kell hozzá. Az lehet, hogy Mac-en ezt az Apple szándéksan akadályozza, mivel ők zárt ökoszisztémára építenek, és azt akarják, hogy tőlük vedd meg a hivatalosan támogatott SSD-t, pont az ilyen görény húzások miatt nem veszek sose Mac-et, pedig telne rá.

Mondom, az NVMe már egy teljesen modern protokoll, nem hagyományos mechanikus meghajtókhoz készült, hanem már célzottan memória/Flash tárolókhoz, ezért nem probléma a firmware frissítése, a TRIM, stb.. Sőt, megfordítva, ezek azért problémásak ATA, SCSI, stb. vonalon, mert csak utángondolásként alkalmazták modern meghajtókra, SSD-kre.

Nagyon elméletileg a gyártó behúzhatja, hogy az NVMe protokoll parancsai közül párat szándékosan nem támogat, letilt, vagy a firmware-ben, vagy a vezérlőben, de ez meg megint görénység, arról nem tudok, hogy a 970 EVO Plus-nál ez a helyzet állna fent.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

nem a macos nem tamogatja, az szepen felismeri, el is kezdheted hasznalni, de ahogy masolod ra az adatokat egy ido utan elcrashel az egesz.  linuxon detto. winen meg szepen mukodik.  valamit nem jol implementaltak rajta, ami win alatt nem jon elo, a tobbi os-re meg tesz a samsung. itt nem az apple a hulyeceg hanem a samsung!

a lenyeg, hogy attol, hogy valami NVME meg ugyanugy lehet bugos, foleg ha samsung, es a gyarto ugyanugy szarik ra mintha SATA lenne...

ja es a 970 Pro tokeletesen mukodik linuxon es macos-en is...

Csak a precizitás kedvéért: a 860 EVO egy ATA-AHCI protokollt használó meghajtó, magyarán SATA interface-es, de van belőle 2,5 colos SATA, mSATA, M.2 SATA változat, az ne tévesszen meg, hogy ezeknek mind más a csatlakozója, és fizikai formátuma, attól még elektronikus szinten teljesen megegyeznek, egy teljesen passzív átalakítóval egymásba drótozhatók probléma és lag nélkül, akár mikroSATA-ra, akár eSATA-ra, vagy amire akarod. Nagyon jól tudom miről írok, nagyon meg kellett néznem, mikor ezt a 860 EVO-t vettem, mert egy olyan régi szubnotiba kellett, ahol már nem volt hely 2,5 colos SATA meghajtónak, és még a korából adódóan az M.2 SATA-t se támogatta, de volt még benne egy mSATA hely, az sem csak mSATA-nak, hanem egy miniPCIe csatlakozó, de konkrétan az mSATA SSD-ket is támogatja, így azért vette bele eleve pont ezt az SSD-t, mert azon kevés SSD-k egyike, amikből még van mSATA-változat, a legtöbb gyártó ezt mára felszámolta, mint elavult formátumot.

Igazából az egész SSD műfaj egy káosz, eleve sok embert az is megtéveszt, hogy M.2-ből se csak egyféle van, hanem van M.2 SATA, M.2 PCIe AHCI (igaz ezt már nem gyártják, talán a Samu 950 volt az utolsó), M.2 PCIe NVMe.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Reported:    2019-05-01 22:00 UTC by Roman Mamedov
Resolved:    2021-09-03 20:51 UTC

https://bugzilla.kernel.org/show_bug.cgi?id=203475

Én problémát nem tapasztaltam velük. #jóvanezígy

"If I had six hours to chop down a tree, I'd spend the first four hours sharpening the axe."

Akkor az m.2 nem erintett, csak a SATA.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Pedantic dickweedery-ben megbújó rejtett subscribe: az m.2 a form factor, van m.2 SATA drive is, az NVME-re mint protokollra gondolsz (aminél consumer szinten valóban az m.2 form factor a leggyakoribb)

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)