Opravdu pomalý SSD disk

[Wasper]

Zdravim,

rad bych se zeptal - mam v kompu disk kompletni low-end disk Crucial BX500 2TB, CT2000BX500SSD1. Po zapisu v radu jednotek az mozna nizkych desitek GB se velmi silne zpomali zapis az na radove 100kByte/s, castokrat s nim i vytimeoutoval i kernel a filesystem to remountlo na r/o pripadne to rovnou vratilo read nebo write error.
Pomoci echo 1 >/sys/block/sdb/device/queue_depth jsem ho presvedcil, ze (vetsinou) kernel drzi, ale rychlost zapisu je porad otresna.

SMART je cisty, kabl ani board to rozhodne nedela (oboje 2x vymeneno), je pravdou, ze je to qlc naprosty lowend, ktery pouziva cast kapacity jako SLC? cache (u prazdneho pry +-kolem 10GB co jsem nasel), coz je konzistentni s tim, co to dela. Zapnuty je porad, a vetsinu casu je idle.

Moje otazky:
1. Je to normalni, ze je to az takhle moc zpomalene?
2. Mam se bat, ze prijdu brzo o data? (vetsina z toho jsou AI modely ktere muzu v nejhorsim stahnout znova, ale ... no mam to risknout, nebo radsi nekde vyhrabat plotnovej a prekopirovat?)

Edit: ext4 noatime, fstrim pomohl opravdu jen na chvili.

[Reklama]

[CPU]

Ano.
Laciné disky často zapisují nejprve do své RAM nebo SLC cache a když se zaplní, tak to cpou na volné místo. Když necháš disku čas, tak to pak rozstrká sám, takže tam za nějakou dobu zase můžeš strkat další GB plnou rychlstí.

Popisované chování může být způsobeno A) vadou, nebo B) tvojí chybou, protože ne-trimuješ C) jinou chybou, kterou samozřejmě na dálku nepoznám

Pokud disk přeplníš a řádně neprobíhá TRIM, pak se dá očekávat přesně tohle chování.
Jak vrátit disku chuť do života?
1. mohl by pomoct skutečně proběhlý TRIM
2. budeš z něj muset vše překopírovat vedle a spustit na Widlích utilitu od výrobce, která disk zaktualizuje, bezpečně smaže a uklidí.

Laciné disky nikdy neobsazuj na 100%, disk smaž tak, aby byl skutečně prázdný
Udělej tam jednu a druhou partition, druhá může být třeba 10% kapacity, ta bude vždy prázdná.
Hlídej si, aby probíhal TRIM.

Pokud to necháš déle, ten disk jsi schopný oddělat.
Takže by ses měl disku ulehčit.

On ti to i výrobce dost jasně říká zde:
https://www.crucial.com/support/articles-faq-ssd/trim-and-ssd-performance-importance


EDIT: Všiml jsem si podivného chování, kdy TRIM nefunguje (!!!), resp. musí ho dělat utilita od výrobce, jinak TRIM neproběhne. Takové chování je hodně otravné, protože na Linuxu samozřejmě neběží utilita výrobce pro Widle, která to TRIMování umí.

https://www.crucial.com/support/storage-executive

[CPU]

...kdo vymýšlel to omezení času...tomu bych dal medaili a poslal ho na východní frontu

EDIT: Všiml jsem si podivného chování ******, kdy TRIM nefunguje (!!!), resp. musí ho dělat utilita od výrobce, jinak TRIM neproběhne. Takové chování je hodně otravné, protože na Linuxu samozřejmě neběží utilita výrobce pro Widle, která to TRIMování umí.

U některých disků! Neříkám že u toho tvého.

A když to budeš mít připojené k Widlím a čistit to, aktualizuj i ten Firmware, celý ho vygumuj, otrimuj a skutečně se přesvěč, že sektory jsou skutečně vygumované.

[RDa]

... mam v kompu disk kompletni low-end disk Crucial BX500 2TB, CT2000BX500SSD1. Po zapisu v radu jednotek az mozna nizkych desitek GB se velmi silne zpomali zapis az na radove 100kByte/s, castokrat s nim i vytimeoutoval i kernel a filesystem to remountlo na r/o pripadne to rovnou vratilo read nebo write error.

Je mozne, ze mas cinsky fejk.

Na druhou stranu.. ten BX500 je lowend a pouziva SM2259XT.. ktery se nachazi i ve spouste fejku.
Takze chovani "nefunguje to" neni bug, ale featura.

[k3dAR]

dle recenze https://www.tomshardware.com/reviews/crucial-bx500-ssd,5377-2.html (slo o 250GB variantu)

se v testu "Transfer Rates – DiskBench" (zapis 50GB, 31,227 ruznych souboru jako fotky, PDF, videa)
=> prumernej zapis 68MB/s a

a v testu "Sustained Sequential Write Performance" (15minut trvaleho sekvencniho zapisu)
=> po zaplneni SLC Cache s ~13GB, spadla rychlost na prumer 100MB/s (resp. dle grafu hopsala 100-140MB/s)

=>=> Takze tva "rychlost": 100kByte/s rozhodne NEni v poradku ;-)
Ten trim si poustel jen rucne? Nemas aktivni: "systemctl status fstrim" (resp. "systemctl status fstrim.timer") ?

BTW: mam v predchozim NB "Crucial MX500 2TB" a v praxi sem nikdy zadnej problem nepozoroval

[Reklama]

[by_cx]

Laciné disky často zapisují nejprve do své RAM nebo SLC cache

To dělají dnes prakticky všechny consumer disky, i ty úplně nejdražší.

Ale k dotazu. Zkusil bych zavolat `fstrim -av` a pokud to nepomůže, tak ten disk vyhodit. I při zaplnění cache by měl jet řádově v desítkách MB/s.

Mám podobnou zkušenost se SATA SSD od WD, kde rapidně klesal výkon až to zasekávalo systém. Musel jsem ho dát pryč. Dlouho mi pak ještě fungoval na Raspberry Pi s HomeAssistantem.

[JmJ]

Podobne chovani sem zazil u tovarniho disku v NTB Lenovo. Dokud mi kamarad nedonesl nejaka velka videa, tak jsem netusil, ze disk je v haji. Pri zapisu velkych soboru po nekolika GB padla rychlost zapisu totalne na hubu. Jine vady disk nevykazoval. Musel pryc.

Stejny typ disku v druhem NTB se rozloucil o nejaky rok pozdeji to pro zmenu chybami cteni i zapisu.

[CPU]

Říkáte:
- disk je vadný
- je to vlastnost disku
- a další

No je to možné, ale s ohledem na to, že tu mám pár disků, které dělají přesně tu stejnou věc, pokud je netrimuje utilita výrobce, pak bych ten disk hned nezatracoval.

Já osobně mám vůbec, u některých disků, problém s trimovací utilitou ať už ve Widlích nebo v Linuxu. Už delší dobu mám podezření, že to prostě neprobíhá.

Proč si to myslím:
První důvod je to, že některým těm disků vrátí rychlost pouze otrimování v utilitě výrobce.

Druhý důvod je měřitelný:
fsutil behavior query DisableDeleteNotify
To nám zjistí, jestli je TRIMování povoleno, pokud je tam 0, pak se může trimovat.
Ok, teď spustíme ruční TRIM z Widlí:
defrag C: /O /L

Retrim: Total space trimmed         = 16,24 GB

Na některých discích můžete ten příkaz pouštět opakovaně i v rámci dnů a vrací se vám stejné výsledky, na discích jiných výrobců se tam pak ukáže nula.
To chování je ještě blbější, pokud takhle načatý disk znovu rozdělíte, bordel se už asi neuklidí.

Ani Linuxová utilita ani Widlí nehází žádnou chybu, ale jako by se nic nedělo.
Pokud spustím násilnější Powershellový skript: Optimize-Volume -DriveLetter C -ReTrim -Verbose Tak to na discích, kde to zlobí, často hází chybové hlášky. Tahle utilita je vlastně jediná, která hlásí alespoň nějakou chyby, byť to není právě ukecané.


Jak jsem to ověřoval:
Vezmu "dirty" disk, který už je pomalý a druhý disk, na kterém vše funguje, připojím je jako D do systému a zkouším je TRIMovat, čekám, že data zmizí, protože disk je "formálně" prázdný. No a právě že ho....ho....zlatá rybko. TRIM ve widlích ani Linuxový to prostě neuklidí. Ale spustím utilitu výrobce a je to prázdné...

No a třeba tomu nerozumím, třeba to chápu blbě, třeba se naprosto pletu.
Já se o tom nechci přít, jen říkám, že jsem uvedené chování pozoroval.

Mimochodem, některé - a hlavně laciné - disky, brutálně likviduje swap.
Za mě, SWAP na laciné SSD disky vůbec nepouštím.

Jinak i odcházející disk má svoje místo na slunci:
Odcházející disk je možné nabouchat daty na 90% a pak mu nastavit atribut RO, může z něj být takový 2TB RO kapsář na data.

[Václav Ovsik]

Disk je na odchodu. Bohužel běžné SSD nejsou tak úžasné jak to na první pohled vypadá. Jako nový SSD frčí, ale jak stárne tak se parametry horší. Pokud dochází k degradaci nábojů v buňkách a hodoty se začnou utápět v šumu, tak musí řadič vyvíjet čím dál větší úsilí data vyčíst a trvá mu to déle a déle. Zpomaluje a nakonec ta data ztratí. Dá se to zase vyřešit tak, že se data přelejou jinam, disk se celý smaže (discard) a data se zase nalejou zpět. Náboje v buňkách se tak občerství.

Jak často je ten disk v provozu? Já myslím, že trochu chytřejší disky, pokud by byly "online" a měli čas na oddech (nebyly pod trvalou zátěží), by mohly kontrolovat náboje samy a provádět refresh v rámci idle...

[CPU]

by mohly kontrolovat náboje samy a provádět refresh

[Michal Šmucr]

Kupoval jsem před asi šesti lety podobný model BX500 240GB (CT240BX500SSD1) jako laciný upgrade do jednoho staršího počítače. Teď je delegovaný na odkládání a nošení v externím SATA USB boxu.
Jinak je to klasická low-end srágora bez DRAM (XT kontroléry od Silicon Motion ji neumí). To moje SSD je modelová řada r. 2018 s TLC.

Má to klasické low-end charakteristiky, co tu byly zmíněné. Malá dynamická SLC, malý overprovisioning, při větším zaplnění to klidně spadne po 10 GB sekvenčního zápisu na 8-16 MB/s. Nicméně mě to nikdy nevypeklo tak, že by to šlo ještě o řád míň nebo to nestihlo zareagovat do timeoutu blokového zařízení. IO depth jsem nikdy nemusel uměle snižovat.
Čímž neříkám, že ty větší a novější QLC modely se nemůžou chovat ještě hůř, nebo že ten váš kousek je vadný.

Žádný magický refresh podle mě není. Ty vendor utilitky do Windows ve výsledku udělají to samé jako blkdiscard celého  zařízení. A vždycky to má v závislosti na používání jen dočasný efekt.

Nevím, asi kdyby to bylo ještě v záruce a dalo se jednoduše replikovat ty timeouty i ve Windows (třeba zápis Crystal Disk Markem a objevovaly se timeouty v Event Vieweru), tak bych to zkusil s popisem chyby vyreklamovat.
V opačném případě by to bohužel letělo do koše.

Jinak při výběru SSD doporučuju občas mrknout na SSD databázi na TechPowerUp.
https://www.techpowerup.com/ssd-specs/
https://www.techpowerup.com/ssd-specs/#Crucial%20BX500

Jsou tam užitečné informace i o rebrandovaných modelech s jinou značkou, různé HW revize, třeba i odkazy na recenze. Někdy tam najdete např. i tu rychlost zápisu ze SLC - folding speed.

[CPU]

po 10 GB sekvenčního zápisu na 8-16 MB/s. Nicméně mě to nikdy nevypeklo tak, že by to šlo ještě o řád míň nebo to nestihlo zareagovat do timeoutu blokového zařízení. IO depth jsem nikdy nemusel uměle snižovat. Čímž neříkám, že ty větší a novější QLC modely se nemůžou chovat ještě hůř, nebo že ten váš kousek je vadný.

Jinými slovy, ten disk jste ve skutečnosti nikdy nedostal do srágorek, ze kterých se nejsnáz dostane jen tak, že ho prostě celý vygumujete, otrimujete, zkontrolujete zarovnání, naformátuje na NULY, znovu otrimujete a znovu naplníte.

Co se děje při velké fragmentaci a neotrimování:
Uvažujme velikost sektoru: 512b
Nejmenší velikost bloku, se kterým disk umí pracovat, může být klidně 16kB.
Takže pak hejbe s hromadou 16kB bloků, aby sem narval jeden sektor a další támhle.
Pokud je disk třeba ještě blbě zarovnaný (logické a fyzické sektory se překrývají), bude to všechno ještě o dost horší.

Ale tohle je jen vaření z vody.
Co udělají v Alza?
Disk smažou utilitou od výrobce a zkusí, jak se chová.
Pokud se bude chovat normálně, tak reklamaci neuznají.

Proto říkám, musí se to zkusit
Bez toho to je jen polévka ze sekerky...
Já netvrdím, že disk nemusí být vadný, ale to, že bez pořádného vyzkoušení se to dá jen těžko zjistit...bez vyzkoušení to jsou jen dojmy...myslet znamená houby vědět.

[BobTheBuilder]

Crucial BX je levná řada, tomu odpovídá i záruka 36 měsíců. Bohužel řadu MX (se zárukou 60 měsíců = výrobce si věří) už prakticky nejde koupit. TBW taky nic moc.
Lepší připlatit na Samsung nebo aspoň na WD Blue/Black, rozhodně ne Green.

[Martin Poljak]

Pokud dochází k degradaci nábojů v buňkách a hodoty se začnou utápět v šumu, tak musí řadič vyvíjet čím dál větší úsilí data vyčíst a trvá mu to déle a déle. Zpomaluje a nakonec ta data ztratí.

Což je problém čtení. U levných SSD disků skutečně nastává, v podstatě to ani není považováno (bůhvíproč) za bug. Zápis by to mělo ovlivnit je nepřímo v tom smyslu, že zapisuje-li řadič malý sektor do celého bloku, může mít problém zbytek toho bloku přečíst.

Dá se to zase vyřešit tak, že se data přelejou jinam, disk se celý smaže (discard) a data se zase nalejou zpět. Náboje v buňkách se tak občerství.

Dá se to vyřešit nástrojem jako badblocks a nedestruktivním R/W testem. Ten z principu své funkce refreshne i bez přelévání dat všechny bloky. (Několikrát ověřeno v praxi.)

Jak často je ten disk v provozu? Já myslím, že trochu chytřejší disky, pokud by byly "online" a měli čas na oddech (nebyly pod trvalou zátěží), by mohly kontrolovat náboje samy a provádět refresh v rámci idle...

Kvalitnější disky to samozřejmě dělají.

[fanoush]

Odcházející disk je možné nabouchat daty na 90% a pak mu nastavit atribut RO, může z něj být takový 2TB RO kapsář na data.

taky by se z toho za chvili mohl vyklubat jen WO atribut a data nikde :-)