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

luks, discard van nálam az /etc/crypttab-ban így hozza létre az Ubuntu 20.04. Ez kb két éve megy így nálam.

nekem par eve az fstrim nyirta ki (kiakasztotta ugy, hogy csak power off utan tert magahoz) az intel ssd-t. nemtom mit csinal, de en kerulom, ha lehet...

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.

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?

500 gigás 860-as samu evo, intel vezérlő, ubuntu 20.04.3, works4me. Eddig nem tapasztaltam semmi hibát, gyors amennyire egy sata 3 ssd gyors tud lenni, boot alatt még a géptől se tudok felkelni és a szobából kimenni olyan gyorsan előjön a desktop.

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