Fórum Root.cz
Hlavní témata => Hardware => Téma založeno: Wasper 06. 03. 2025, 21:37:24
-
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.
-
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
-
...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é.
-
... 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.
-
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
-
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.
-
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.
-
Ří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.
-
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...
-
by mohly kontrolovat náboje samy a provádět refresh
(https://tenor.com/EQgu.gif)
(https://giffiles.alphacoders.com/901/90105.gif)
-
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.
-
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.
-
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.
-
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í.
-
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 :-)
-
taky by se z toho za chvili mohl vyklubat jen WO atribut a data nikde :-)
Mohl, ale to se ti může stát i u normální disku, klidně i plotny.
Pár takových disků mi tu "umírá" už pár let a pořád se jim nechce (bohužel mix. SATA/NVMe/U.2)
Jeden je v provozu 24*7 a čte, čte, čte a čte, byť na něj poslední tři roky nešel ani jeden zápis :)
resp. ten disk si napozadí něco dělá, protože mu životnost ze 3% klesla na 2%, ale touhle rychlostí bude na 0% za čtyři roky ;D
-
Diky vsem za rady. trim jsem delal nekolikrat - prvne byl v cronu, pak se vsechno premazalo a udelal se pri mkfs, pak nekolikrat rucne.
To s tim Windozim toolem od vyrobce je dobry hint, zkusim, jinak se asi smirim, ze mam extra spatny kus (to jsem necekal) levneho extrasmejdu (to jsem cekal).
-
Ten discard celýho disku jde udělat i v Linuxu, není třeba Windows nástroj. Ale smaže to všechno na disku
sudo blkdiscard /dev/sdd
-
Problém u tohohle SSD je, že výrobce deklaruje výkon jen v situaci, je-li disk nový, popř. při uvedení do stavu "jako nový" pomocí Secure Erase. Nic víc. Neuvádí nic jako nejmenší možná rychlost a podobně. Takže pokud SSD podle specifikace "po Secure Erase v CrystalDiskMarku při nastavení Queue Depth 32 se zapnutou write cache umí udělat zápis 500 MB/s a čtení 540 MB/s", tak bohužel není co reklamovat.
-
Myslím, že pokud se disk dostává do stavu, kdy nereaguje na OS a ten vyhlašuje timeout chyby, tak to na reklamaci je.
Jedině, že by toto chování bylo popsáno v manuálu s informací, jak se mu vyhnout - např. vždy nechat na disku alespoň 10% volného místa, jinak hrozí popsané chování.
-
při uvedení do stavu "jako nový" pomocí Secure Erase. Nic víc.
Presně.
Až to majitel zkusí, uvidí se, co dál.
Tyhle disky nejsou vůbec špatné, když se používají tak nějak vhodně.
-
Diky vsem za rady. trim jsem delal nekolikrat - prvne byl v cronu, pak se vsechno premazalo a udelal se pri mkfs, pak nekolikrat rucne.
To s tim Windozim toolem od vyrobce je dobry hint, zkusim, jinak se asi smirim, ze mam extra spatny kus (to jsem necekal) levneho extrasmejdu (to jsem cekal).
Mám ten istý disk už 2,5 roka a popisované problémy nemám. Je to na reklamáciu. Ten disk je síce pomalý, ale nie až tak. On začne ládovať tak ako má v papieroch, čiže 600 MB/s a po pár sekundách klesne na pár sekúnd na 20 MB/s, zrejme kým sa neuvoľní cache, a potom sa opäť vráti na plnú rýchlosť. Trimom to určite nie je. Navyše, aj keď spomalí, tak na systém stále reaguje.
Mal som kedysi disk, ktorý vykazoval permanentne takéto rýchlosti asi pol roka od kúpy. Tak som ho pre istotu prešiel kontrolou povrchu disku. Našiel som 8 vadných sektorov a išiel na reklamáciu. Keďže to bolo SSD (WD Green 240 GB), tak mi predajca povedal, že som mal šťastie, že som dokázal ešte odzálohovať všetko potrebné, pretože SSD zvyčajne skončí úplne.
Takže na tvojom mieste by som reklamáciu (ak nie je neskoro) určite neodkladal.
-
a popisované problémy nemám. Je to na reklamáciu.
Vy kluci asi netušíte, jak to vypadá, když TRIM nejede...
-
a popisované problémy nemám. Je to na reklamáciu.
Vy kluci asi netušíte, jak to vypadá, když TRIM nejede...
Pouč, pls, jaxe to pozná a jaxtoho ven?
-
Pouč, pls, jaxe to pozná a jaxtoho ven?
XorryVe, nexi maXchrovat, gzy gzy gzy iii bil bich traXpnej.
-
Pouč, pls, jaxe to pozná a jaxtoho ven?
XorryVe, nexi maXchrovat, gzy gzy gzy iii bil bich traXpnej.
Voe, Téď machruješ, a moh sem taky napsat jak100hoven.
ne fakt, mě by to opravdu zajímalo, jak se pozná, že mi nefunguje trim. Dávám do starejch pleček sata SSDčka, a už mi nějaký umřelo, tak jestli to nejni třeba tím... Mám tam různé OS - XP, 7, 10, 11, linux...
-
Ale ve vláknu to už je napsané i to, proč si to myslím. Bez toho, aby původní tazatel napsal, jestli to pomohlo, se dál nedostaneme.
A je recept, jak NÉKTERÉ LACINÉ SSD do takového stavu dostat.
- vypnout TRIM
- vytvořit nezarovnaný oddíl
- disk zapnit k prasknutí hromadou souborů (napr. dekompresí)
- odmazat cca 40 GB místa, aby vůbec mhla fungovat SLC cache
- spustit rozbalení archivu nebo kopírování většího množství malých souborů
U některých disků ti po zaplnění SLC cache rychlost klesne na jednotky MB, protože disk se snaží vyprázdnit SLC cache, pere se s tím, co tam rveš a ještě se na pozadí se snaží utilizovat souborový systém.
Jeden disk mi takhle jel řádově jednotky MB/s a stačilo ho uvést do továrního nastavení, aby zase jel normálně....doteď funguje. Jen musí běžet utilita výrobce, protože widle ho neotrimují + zarovnaní + trik s vyhrazením 10% místa, dokud je disk úplně prázdný (hned při prvním použití).
Ad tazatel:
- měřil správně?
- neovlivnila mu měření nějaká úloha?
- kopírování bylo z disku X na X nebo disk Y nebo z USB třeba?
- jaký typ dat to byl?
- jak plný má disk, starý OS?
- ...
Jen polévka ze sekerky...
A třeba JE tenhle disk vadný nebo fejk, ale jak to chceš poznat, když to nezksíš?
-
Ano, tohle všechno zmíněné je sice fajn a za určitých podmínek to třeba může pomoct.
Nicméně, a teď píšu čistě ze své zkušenosti s řádově vyššími desítkami modelů a typů v nejrůznějších cenových hladinách tzn. od serverových, USB externích, standardních TLC/QLC low-endů až po ty nejhorší OEM srágory, co se dávají do základních notebooků - pokud to SSD nebylo vadné, nebo nahnilé, třeba když mi ho někdo donesl na pokus s vytažením dat, tak se mi nestalo, že by neodpovědělo do výchozího timeoutu.
Tohle je za mě prostě red-flag. Může se to třeba plazit, být ne-trimované (což je vcelku easy např. u NTFS-3G oddílů na Linuxu nebo za řadičem, přes který to neproleze), být plné a mít relativně dlouhé latence. Ale ten výchozí timeout je 30 s v Linuxu a na macOSu, ve Windows pak u storportu 10 s. To je fakt na tenhle typ úložiště docela dost. Až když je tam nějaká bloková operace, co tam visí déle, tak se filesystém, který pak typicky nemůže dokončit synchronní zápis do žurnálu, přepne do R/O.
Takže, já bych na tu optimalizaci úplně nesázel, i když zkusit se to určitě dá. I když jak jsem psal, spíš bych se toho snažil zbavit nebo vyreklamovat.
Špatné zarovnání nebývá moc typický problém, všechny běžné nástroje a instalátory už s tím tak 10-15 let počítají a rovnají oddíly na 1MB. Takže to by se musel člověk buď opravdu snažit nebo třeba klonovat tabulku 1:1 z nějakého prehistorického disku. Ale je to snadné ověřit, třeba přes parted (align-check).
-
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.
Zrovna tenhle kousek jsem opravdu nešetřil, za těch šest let byl fakt na spoustě různých místech, včetně toho že byl téměř úplně plný, měsíce se netrimoval oddíl (NTFS3G) a byly na něm něm torrenty u RPi, měl jsem na něm i qcow2 image s nějakými pokusy, když už se mi nevešly primární pool atp.
Nicméně to je teď vcelku jedno.
Spíš mě trochu zarazily ty doporučované procedury.
Předpokládejme, že tam není chyba v zarovnání (nepravděpodobné, a jednoduše jde ověřit).
Přesunete data jinam, spustíte TRIM (všechny položky na neobsazených LBA se ve FTL mapě v SSD zneplatní), zkopírujete data zpátky.
Po tom kopírování zpátky to už bude kontinuálně zapsané, ideálně rozložené na všechny čipy a odstraní se všechny "díry" a diskontinuity po předchozím GC, když se na původním filesystému modifikovaly soubory.
Tohle v drtivé většině úplně stačí a nejsou potřeba další kroky.
Jestli to z nějakého důvodu chci odstranit sakumprásk včetně filesystémů s jejich metadaty, tabulky s oddíly atp., použiju blkdiscard, který TRIMuje všechna LBA na daném zařízení. Ale zas jako předtím to pracuje jen s tou mapou.
Byť jak jsem předtím zmiňoval, byť moc nevěřím na nějaký magický refresh, tak pokud bych chtěl jít opravdu do všech buňek i mimo uživatelskou oblast, tak rozhodně nebudu posílat žádné "NULY", ať už při inicializaci fs, nebo třeba přes dd if=/dev/zero of=/dev/sda.
Už i třeba kvůli tomu, že krom toho, že to trvá dlouho a leze to zas přes SLC, tak na buňkách to ve valné většině jako žádné nuly nekončí. Je tam po cestě typicky nějaká forma scramblingu.
Kdybych tohle chtěl, tak použiju přímo ATA command.. SECURITY ERASE UNIT, který se dá spustit na Linuxu přes hdparm a na Windows přes ty vendor utilitky.
https://www.putorius.net/securely-erase-a-sata-hard-drive-hdparm-linux.html
To je blokující operace, která typicky udělá to, že firmware SSD smaže komplet všechny položky ve FTL mapě a restartne firmware.
Je tam ale i varianta příkazu SECURITY ERASE UNIT ENHANCED. Tam už buňky přepíše výchozí hodnotou (u NANDů to bude nejspíš 1) a trvá to déle, i když pořád řádově rychleji než z hosta.
Nicméně pořád záleží, co tam přesně konkrétní výrobce ve FW implementuje, někdy oba příkazy udělají to samé.
Trochu novější variantou, která byla přidána až do pozdějších variant toho ATA standardu, je pak SANITIZE. Ten je ve třech variantách BLOCK ERASE, OVERWRITE a CRYPTO SCRAMBLE. Ta první víceméně odpovídá staršímu SECURITY ERASE, další
má pak možnost přepsat bloky nějakým čtyřbajtovým patternem s volitelným počtem přepisů (ale používá se primárně na HDD a SSD ji moc neimplementují) a poslední je pak verze pro SEC (self-encrypting) SSD, kde to smázne klíče.
Taky se to dá spustit z hdparm (i když to není v manuálových stránkách, jen v helpu po spuštění příkazu).
Víceméně analogické příkazy jsou pak i na SCSI/SAS nebo NVMe.. tzn. spustitelné přes sg3_utils nebo nvme-cli.
-
Víceméně analogické příkazy jsou pak i na SCSI/SAS nebo NVMe.. tzn. spustitelné přes sg3_utils nebo nvme-cli.
To je určitě zajímavé a poučné.
Tyto utility na linuxu v podstatě až tak nepotřebuji, protože řeším hlavně úlohy náročné na čtení dat. Ale je to dobré vědět!
Ale ad ty nuly.
Máte i nemáte pravdu.
Také jsem si *myslel*, že se nuly při formátování nezapisují (klasický pomalý formát), resp. že se nezapisují na SSD, protože je vše komprimované a optimalizované....na to mi jeden člověk od Micronu řekl, že takové věci často zahrnují alespoň i základní deduplikaci, že se to blbě ladí a že nemám mít o schopnostech nejlacinějších řadičů přehnané představy.
Ano, asi by byl fajn vzít pár disků a povrtat se v tom. Ad timeouty: bez kooperace s původním tazatelem se to dá diagnostikovat těžko.
Napadlo mě, že jsem viděl i vadný SATA kabel, pár GB se uložilo do mezipaměti a pak začal cirkus.
Ale může to být i ve špatném M.2 konektoru, stačí špína a problém je vyrobený.
Jinak problemy na SATA se v posledních pár letech objevovaly... dejte si do Gogle msi sata slow
a asi se nebudete divit....
Netvrdím nic, jen to, že prohlásit "ssd je fakt vadný"...je pněkud málo podložeo důkazy...byt samozřejmě třeba vadné je.
-
...
Po tom kopírování zpátky to už bude kontinuálně zapsané, ideálně rozložené na všechny čipy a odstraní se všechny "díry" a diskontinuity po předchozím GC, když se na původním filesystému modifikovaly soubory.....
ehm ...
SSD ti nikdy nikam nic kontinualne nezapise, protoze jako prvni prepise bunku ktera ma nejnizsi citac. A jakym zpusobem jsou ty bunky rozhazeny ty nemas naprosto zadnou moznost zjistit.
Pokud je SSD vicemene plne, tak ma jen dve moznosti. Neustale osoupavat ty zbyvajici bunky. Nebo setrvale presunovat data. Coz pochopitelne vede k tragickym vykonum.
Specielne, kdyz bezna velikost ty bunky je MB a vic ... zatimco vetsina fs se drzi 512B per sektor.
-
Specielne, kdyz bezna velikost ty bunky je MB a vic ... zatimco vetsina fs se drzi 512B per sektor.
Máš pravdu, ale seběhnou se na tebe křiklouni...
Velikost nejmenší zapisovací buňky je 4-16kB = SSD umí zapsat nejméně 4-16kB a to i při změně 512B sektoru.
To je nejmenší blok, který řadič umí zapsat.
Ale - ošoupávací mapa - tedy to, v jakém je ten blok stavu, je skutečně často poměrně velký.
Příklad:
Mám 2TB SSD = 2 147 483 648 B
To je: 536 870 bloků o velikosti 4 kB!
Pokud bych pro každý takový blok uchovával nezbytné informace jako:
- ECC
- stav opotřebení
- poslední změna
- kam byl přemapován (SSD má náhradní buňky)
...
No tak bych spotřeboval poměrně významnou část kapacity jen na ukládání informací o těchto blocích. A jak by se to vlezlo do paměti toho řadiče???
Dovedete si představit, že před zápisem každého 4kB bloku by se muselo uskutečnit čtení z SSD, která buňka je nejméně ošoupaná a po zapsání toho 4kB bloku tyto hodnoty změnit?
Bloky pro zhodnocení stavu opotřebení tak jsou opravdu poměrně velké.
A další důležitá věc, funguje to na principu zásobníku a je za tím logika, ne že ne.
-
Specielne, kdyz bezna velikost ty bunky je MB a vic ... zatimco vetsina fs se drzi 512B per sektor.
Máš pravdu, ale seběhnou se na tebe křiklouni...
Velikost nejmenší zapisovací buňky je 4-16kB = SSD umí zapsat nejméně 4-16kB a to i při změně 512B sektoru.
To je nejmenší blok, který řadič umí zapsat.
Ale - ošoupávací mapa - tedy to, v jakém je ten blok stavu, je skutečně často poměrně velký.
Příklad:
Mám 2TB SSD = 2 147 483 648 B
To je: 536 870 bloků o velikosti 4 kB!
Takhle se to nedela.. typicky se hraje na Erase units (EU), coz je 512K - 1MiB - 2MiB, ktere jsou prvni urovni.
V kazdem EU jsou pak zapisovany data stylem COW sekvencne. Takze staci sledovat pocet resetovani tech EU.
Chce to nastudovat trocha vic o FTL (existuje na to spousta paperu), nez brat za fakt, ze to je udelano, jak vas napadne.
-
Ale ad ty nuly.
Máte i nemáte pravdu.
Také jsem si *myslel*, že se nuly při formátování nezapisují (klasický pomalý formát), resp. že se nezapisují na SSD, protože je vše komprimované a optimalizované..[/b]
Nejspíš jsme se nepochopili úplně. Já to komentoval z hlediska toho, že když se posílají z hosta nuly, tak to neznamená, že na SSD skončí na úrovni těch NANDů také nuly. Ano, sice přepíšu většinu bloků jinými daty, udělám hromadu zápisů z hosta, naplním celou FTL mapu.
Nešlo ani o to, že bych v tu chvíli řešil případný dedup, ale zmíněný scrambling, který je používaný na většině SSD (možná mimo prvních full SLC). Je to forma pre-processingu dat, aby se minimalizovaly chyby spojené s opakujícími se krátkými vzory (např. samé nuly) při zápisu a čtení z těch NANDů.
Takže data se zapíšou do SLC cache a před zápisem do těch finálních vícestavových buňek se zakódují. Buď nějakým speciálním klíčem, co se uloží bokem, nebo použitím nějakého přirozeně se měnícího klíče z existujících údajů. Např. složený např. z logické adresy, fyzické adresy a počtu zápisů do daného bloku. Tím se pak XORují všechna data.
Při čtení se zas naopak relativně jednoduše dekódují.
Jinak ten SECURE ERASE příkaz pokud je někde dokumentovaný od výrobce, tak má často jen napsáno, že krom toho smazání uvede bloky do "továrního" stavu. Což může to znamenat oboje - jak tohle "zašumění", tak i opravdové faktické vynulování (nebo vyjedničkování :) ) bloků.
Jak jsem psal, tak bude hlavně záležet jak budou v konkrétním kontroléru a firmware implementované tyhle dva příkazy. Např. hdparm -I vypíše i odhadovanou dobu ERASE i ERASE ENHANCED celého SSD. U některých modelů je to stejná doba, např. 2 min, ale viděl jsem i Samsungy, co třeba hlásily 2 min pro ERASE a 40 min pak pro ERASE ENHANCED.
Každopádně je to, jak zmiňujete. Veřejně přístupné informace o konkrétních modelech jsou od výrobců vcelku mizivé, a taky mě kolikrát zajímalo, co je tam reálně zapsáno. Vcelku logicky z hosta se nic zjistit nedá, protože i po běžném trimování prostě při čtení z LBA, která nemá platný záznam v FTL mapě, ten firmware vždycky vrací nuly.
Takže jediná šance je to nejspíš relativně komplikovaně přečíst na HW úrovni. I když nejspíš budou existovat i speciální firemní nástroje, nebo firmware.
-
SSD ti nikdy nikam nic kontinualne nezapise, protoze jako prvni prepise bunku ktera ma nejnizsi citac. A jakym zpusobem jsou ty bunky rozhazeny ty nemas naprosto zadnou moznost zjistit.
Pokud je SSD vicemene plne, tak ma jen dve moznosti. Neustale osoupavat ty zbyvajici bunky. Nebo setrvale presunovat data. Coz pochopitelne vede k tragickym vykonum.
Specielne, kdyz bezna velikost ty bunky je MB a vic ... zatimco vetsina fs se drzi 512B per sektor.
To je jasné, že ty konkrétní fyzické adresy samozřejmě přímo neovlivníš. Já jsem spíš myslel víceméně kontinuální zápis z hlediska LBA a pořadí celých souborů při kopírování zpět ze zálohy po jejich předchozím kompletním smazání a TRIMu.
Ano fyzická alokace záleží na spoustě faktorů. Bere se v potaz např. seznam vadných bloků (i s nějakými výchozími záznamy už z fabriky), nějaký optimální proklad pro paralelizaci, tak i zmíněné informace o počtu zápisů, kvůli wear levelingu .. plus tam bude celá řada dalších a většinou proprietárních optimalizací.
U té logické alokace to také není nutně zcela lineární a určitě hraje roli konkrétní file systém a jeho nastavení (jinak se bude chovat ext4, XFS s alokačními skupinami a třeba ZFS).
Nicméně přes tohle všechno tímhle celým procesem po určité době standardního používání výrazně defragmentuješ jak filesystém, tak i fyzické uložení. Při kopírování na prázdné SSD v podstatě při foldingu/GC budou brát celé volné bloky bez potřeby dalších RMW cyklů. A jak jsem už říkal, udělá se v rámci možností víceméně optimální proklad. Také pak na konci kopírování zbyde v porovnání s výchozím stavem typicky daleko vyšší počet celých volných bloků, což může u některých modelů ovlivnit i velikost dynamické SLC cache.
Proklad je jeden ze znatelných problémů, který třeba řeší výzkumníci ze Samsungu. Po nějaké době používání, kdy se zvýší fragmentace a ty sekvenční části souboru jsou pak nerovnoměrně rozložené mezi čipy (jsou tam hotspoty), se prodlužují latence při čtení.
Ještě jen k terminologií (aspoň jak ji používám já).
chip -> die -> plane -> block -> page (subpage) -> cell
Nejmenší část s daty je cell.
Nejmenší část pro čtení je page (někdy i subpage, jak to pojmenovávají někteří výrobci, když je SSD přepnuté do režimu kompatibility, kde použitá menší než nativní page), mívá třeba 4-16 Kb.
Jak zmiňuje RDa, tak nejmenší část která se dá přeprogramovat je blok, který má něco jako 64 nebo 128 stránek (což je asi ten 1 MB, co jsi psal).
Jinak filesystém pak má dneska spíš 4kB velikost bloku (clusteru u NTFS), ne 512B.
Což mě vede ještě k jedné věci, která mi přijde, že tu občas v diskuzích trochu zapadá. V praktickém používání hraje velkou roli i optimalizace na úrovni blokové vrstvy a IO scheduleru. Ten například standardně spojuje krátké requesty podle jejich LBA. A to až do maximální délky requestu, co podporuje HW. Tzn. když tam bude v nějakém čas. intervalu hromada kratších write requestů (např. 4k bloky fs) s vzestupným adresováním, bude se to spojovat až do 1M requestů, co se pak následně budou posílat do disku. Jinak ještě tohle logicky nejde dělat, když ty zápisy neprochází přes page cache, tzn. např. režimy s direct nebo sync.
Podobně jdou spojovat i nekontinuální čtení nebo zápisy do jedné operace s pomocí scatter-gather listů, což pak třeba hardwarově podporují některé novější NVMe disky.
-
Ještě jen k terminologií (aspoň jak ji používám já).
chip -> die -> plane -> block -> page (subpage) -> cell
Melo by to byt s prohozenym block->plane v teto logicke hierarchii.
Protoze BLOCK jde mazat, ale PLANE (u MLC) jen programovat.
SLC cache je v podstate omezeni se na zapis jen do prvni plane.
-
Ještě jen k terminologií (aspoň jak ji používám já).
chip -> die -> plane -> block -> page (subpage) -> cell
Melo by to byt s prohozenym block->plane v teto logicke hierarchii.
Protoze BLOCK jde mazat, ale PLANE (u MLC) jen programovat.
SLC cache je v podstate omezeni se na zapis jen do prvni plane.
Já myslel spíš tu klasicky používanou hierarchii podle konstrukce NAND čipů a velikosti jednotlivých částí od největšího do nejmenšího a kde jsou v die např. dvě až čtyři plane, v každé z nich je mnoho bloků, v který jsou page atd.
Jak na ty noční odpovědi koukám teď, tak jsem tam udělal chybu (oh my, chtělo by to po sobě líp číst :( ). Měl jsem tam samozřejmě napsat, že programovat (write) jdou i čisté, smazané page, ale mazat pak jde jen celý blok. Což pak při změně vynucuje ty RMW cykly při nutnosti změny dat v rámci jedné page.
Ale určitě tam při popisu některých operací můžou být i jiné vazby. Třeba u některých modelů se zhusta využívá možnosti paralelního provádění více operací R, P, E na všech plane v die současně jedním příkazem (operuje to typicky se stejným blok offsetem v rámci plane).
Stejně jako některé modely popsané v paperech pak používají i něco, čemu říkají superblok (skupina bloků v rámci všech plane, které mají stejné ID - relativní umístění v plane) a superpage (všechny stránky se stejným relativním umístěním v blokách, co tvoří superblok). Což pak používají na paralelizaci, tak i na další paritní data v rámci těchhle skupin.
Viz. příloha a celý dokument na https://arxiv.org/pdf/1711.11427 (sekce 1.1 Flash Memory Organization)
-
Jenze ono je uplne jedno jak je to SSDcko udelany uvnitr. Problem je uz drahne let rozbita storage pipeline.
Proste prisel buh a rekl budiz disketa .... a od ty doby ma vsechno clustery a sektory. A pak se mezi to vymejslej ruzny fejky a konverze, ktery to rozbijej cim dal vic.
Jen kdyz vemes disk vs ssd, tak tu mas hnedle 3x3 faily. Prvni fail je v tom, ze ten disk/ssd fejkuje svoje usporadani. Widle cislo dve ti do toho hodi raid, kterej pouziva nejakou velikost stripe, ale fyzicky vyuziva nejakou velikost bloku nafejkovanou tim diskem. A treti widle ti do toho hodi fs, kterej opet pouziva nejakou svoji velikost bloku, ale vzadu pouziva bud ten stripe nebo tu nafejkovanou velikost z toho disku.
Pak to muzes vynasobit 3x na tema zarovnani, kdy ty fekovany data z disku nesedej na jeho fyzicky rozdeleni, nesedi na to ani stripe a nesedi na to fs.
A aby to jakoze aspon obcas nejak fungovalo, tak se vymejslej prave takovy veci jako trim. Misto aby se odstranilo to fejkovani.
Mimochodem, disky v polich jsou specificky prave predevsim tim, ze maji vsechny tyhle frikulinsky funkce vypnuty, a vsechno si ridi prave pole.
-
Stejně jako některé modely popsané v paperech pak používají i něco, čemu říkají superblok (skupina bloků v rámci všech plane, které mají stejné ID - relativní umístění v plane) a superpage (všechny stránky se stejným relativním umístěním v blokách, co tvoří superblok).
Tak moje pojeti bloku co se maze bylo tedy "superblock", co se maze (tj skrze vsechny planes). Programuje se pak urcita "page" prislusejici k bloku (ktery to je plane je pak implicitni - ono treba cislovani bloku je sekvencni - kdyz ma cip 2048 bloku na 2-bit MLC, tak sude bloky jsou v jedne plane, a liche bloky jsou v druhe plane).
Tak mozna takle tedy: package -> channel -> die -> E:superblock -> block(@plane) -> W:page -> byte
Paralelizace je mozna klasicky na urovni die. A ted nekdo tohle schema udelejte s V-NAND (a treba zaroven na QLC)
(ty 2/3/4 planes si predstav jako vsechny n-te bity nejake mlc/tlc/qlc bunky .. kazda dalsi plane ma polovicni uroven naboje co se programuje.. ale maze se vsechno)
-
Mimochodem, disky v polich jsou specificky prave predevsim tim, ze maji vsechny tyhle frikulinsky funkce vypnuty, a vsechno si ridi prave pole.
Keep dreaming. Disky v polich jsou obycejne blokove zarizeni.
Ano, nekdy jde o host-managed (zoned storage), ale samotna zona taky prochazi skrze FTL a nemas sanci zjistit na ktere lokaci ve flash je.
Takovej tupej disk, co mu muzete prepisovat jeden sektor dokola a tim ho znicit byl naposledy v dobe USB flashek bez FTL, a nektere prvni mala flash media to fotaku, kde se o wear levelling staral uzivatel - jakmile byla karta plna, tak ji vyndal, zkopiroval a smazal.
-
Me napadla dalsi vec, kterou jsem praktikoval u mych ssd disku. Proste jsem mu vytvoril prazdny oddil cca 8-32GB, aby ssd radic nemusel pri zaplneni nebo pri nepouzivani fstrim ( a to jak v cronu nebo mountnute s discard ) prepisovat nekolikanasobne vice bloku.
-
A aby to jakoze aspon obcas nejak fungovalo, tak se vymejslej prave takovy veci jako trim. Misto aby se odstranilo to fejkovani.
myslim ze FTL primo v disku ma i nejake vyhody - blokova vrstva kde te skoro nezajima co je pod tim a das si na to jaky fs chces neni tak spatny napad. To o cem mluvis je treba ubi a ubifs v linuxu (drive treba jffs2) a myslim ze zadna velka vyhra to neni. treba s prichodem MLC nejakou dobu trvalo nez do UBI pridali podporu MLC a jelo se zatim v SLC rezimu s polovinou kapacity, tezko by to realne stihalo s vyvojem jaka v tehle oblasti je a i ta slozitost porad roste a prostor pro chyby je tam velka.