Kontrola a refresh SSD disku?

[registrovany_ava]

Mám SSD disk (konkrétně https://pevne-disky-externi.heureka.cz/verbatim-store-n-go-mini-1tb-53237/#prehled/), zálohuju si na to fotky a další. Pro jistotu mám dva a ještě ukládám do cloudu, ale stejně by mě zajímalo

 - Slyšel jsem, že z uložených bitů může postupně unikat náboj a ztrácí se tak informace. Je to tak? Je možné nějak disk zkontrolovat, jestli už k tomu nedochází (třeba že bych jednou za rok ověřil, že nějak nestárne)?
 - Dávalo by třeba jednou za rok smysl všechna data přečíst a zapsat, abych data takto "občerstvil"? Nějaké in-place dd? Existuje na to nějaká utilita?

[Reklama]

[alex6bbc]

co to je in place dd, jak mas linux, tak mas dd :-)

zaloha ma byt na vice mistech i geograficky na vice mistech.

[Jan Forman]

SSD vyžadují napájení... pokud jsou napájená, řeší si obnovu i verifikaci sám kontroler. Netřeba dělat nic.

Bez energie tak cca 1 rok pravděpodobně TLC disk už nebude čitelný, u QLC už to může být i půl roku.
Každý disk vykazuje jinou míru zapomínání a proto nelze přesně odhadnout, kdy k tomu dojde.

Prakticky jsem to viděl jen jednou, známý si nechal SSD disk v šuplíku a vrátil se k němu po roce.
Data už nebyla v pořádku, ale po naformátování zase fungoval dál.

[registrovany_ava]

SSD vyžadují napájení... pokud jsou napájená, řeší si obnovu i verifikaci sám kontroler. Netřeba dělat nic.

Bez energie tak cca 1 rok pravděpodobně TLC disk už nebude čitelný, u QLC už to může být i půl roku.
Každý disk vykazuje jinou míru zapomínání a proto nelze přesně odhadnout, kdy k tomu dojde.

Prakticky jsem to viděl jen jednou, známý si nechal SSD disk v šuplíku a vrátil se k němu po roce.
Data už nebyla v pořádku, ale po naformátování zase fungoval dál.

Díky, to je mimořádně zajímavá informace. Mohu poprosit o zdroj? Ne že bych tomu nevěřil, ale rád bych si přečetl víc.

[Jan Peterka]

Já si myslím že je to hloupost. Sám jsem kopíroval zálohu několika Gb z uloženky ssd něco přes tři roky nepoužívaného a vše be problémů. Více zkušeností tady: https://www.abclinuxu.cz/poradna/linux/show/492557

[Reklama]

[e3k]

fstrim --all

[Michal Šmucr]

SSD vyžadují napájení... pokud jsou napájená, řeší si obnovu i verifikaci sám kontroler. Netřeba dělat nic.

Přesně tak.

Díky, to je mimořádně zajímavá informace. Mohu poprosit o zdroj? Ne že bych tomu nevěřil, ale rád bych si přečetl víc.

Co vím, jsou v podstatě dvě kategorie SSD, které ve svých dokumentech definuje JEDEC - Client (consumer) a Enterprise.
V té první by měla data vydržet - 1 rok při 30 st. C, u druhé 3 měsíce při 40 st. C.

viz. Retention Use (power off) na stránce 26
https://www.jedec.org/sites/default/files/Alvin_Cox%20%5BCompatibility%20Mode%5D_0.pdf

Ty celé dokumenty s odpovídajícími standardy JESD.... jsou bohužel neveřejné (jen pro členy JEDECu).
Ale je k dispozici výše zmíněná prezentace, kde je docela hutný výtah. Včetně metodik pro určování výdrže, specifikace testovacích workloadů atp.

Já si myslím že je to hloupost. Sám jsem kopíroval zálohu několika Gb z uloženky ssd něco přes tři roky nepoužívaného a vše be problémů. Více zkušeností tady: https://www.abclinuxu.cz/poradna/linux/show/492557

To bohužel neznamená, že se na to můžete spolehnout. Ty výše zmíněné standardy neříkají, že to ztratí data za danou dobu. Nicméně pokud konkrétní SSD nemá ve své specifikaci uveden nějaký delší čas, kdy vám bude výrobce garantovat, že to udrží data bez napájení, tak bych všechno nad tyhle základní údaje v JEDEC normách (podle kterých to testují a udávají specifikace) bral jako bonus.
Osobně mi také SSD víceméně drží data, ať už třeba vyřazená v nějakých SATA->USB krabičkách, v podstatě na odkládání, nebo třeba jako systémové disky ve stanicích, které jsou ve skladu předinstalované jako náhradní. Ale rozhodně bych to nebral jako médium pro nějaké off-line uchovávání důležitých dat. Minimálně bych to občas celé zapnul a třeba verifikoval data podle nějakých kontrolních součtů, co mám uložené jinde.
Tím nejen ověříte integritu, ale určitě zabere ten controller uvnitř a stoprocentně přistoupíte ke každé buňce, kde máte uložená data.

[Michal Šmucr]

fstrim --all

To vám spustí trim na všech připojených filesystémech, které podporují trimování. Včetně třeba systémového disku, což většinou nechcete atp.

Tohle rozhodně samo o sobě neřeší nějaké "osvěžení" paměťových buňek z hlediska udržení informace, jen to pošle odpovídající HW příkaz (TRIM, UNMAP, deallocate) pro bloky filesystému, které jsou neobsazené. Můžete to dělat buď automaticky na pozadí, když filesystém maže data (pokud má mount volbu discard), nebo právě jednou za čas manuálně přes fstrim.

Je fakt, že u některých zoufalých SSD, které třeba vykazují velká zpomalení v některých částech své celkové kapacity, tohle může pomoct (než ho třeba definitivně vyhodíte), ale neřeší to přímo zmíněnou životnost dat.
Nicméně když už to je v tomhle stavu, že tohle budete chtít vyzkoušet, tak je lepší přesunout všechna data, odmountovat a zrušit filesystémy na disku a pustit spíš příkaz blkdiscard.
Ten narozdíl od fstrim nepracuje s jednotlivými volnými bloky filesystému, ale pošle do zařízení najednou celý rozsah sektorů, které má uvolnit. Bez parametrů je to komplet celé zařízení, ale dá se specifikovat i třeba nějaký rozsah (offset, délka).
Jinak je blkdiscard samozřejmě dobrý také třeba, když řešíte nějaký thin-provisioned disk, kde rušíte staré filesystémy, a budete vytvářet nové.

[Michal Šmucr]

V té první by měla data vydržet - 1 rok při 30 st. C, u druhé 3 měsíce při 40 st. C.

viz. Retention Use (power off) na stránce 26
https://www.jedec.org/sites/default/files/Alvin_Cox%20%5BCompatibility%20Mode%5D_0.pdf
uložená data.

Jen aby to nevyznělo tak tragicky, zapomněl jsem zmínit, že na další stránce je celá tabulka (podle modelu na zrychlené testování, podobně jako u jiných médií to samozřejmě nikdo nemůže zkoušet v reálném čase .
Při nižší teplotě, data drží samozřejmě déle.

[k3dAR]

na kontrolu, udelat si kontrolni soucty vsech souboru a kontrolovat zda odpovidaji...

to in-place-dd muze asi zaridit badblocks, s parametrem -n (ne-destruktuvni write test)
kterej nacte puvodni block do ram, pak tam neco zapise, zjisti zde se zapsalo spravne a vrati tak puvodni block

Kód: [Vybrat]

badblocks -n -v -s /dev/sdX
ale nevim nakolik je to opravdu "reseni" a uz vubec neresim zda je to nutne a jak casto
+ zaroven pocitat s tim ze 1 takovy test udela 2x zapis celeho disku
+ nedelat to na disku s 1 zalohou(ale kdo by mel jen 1 zalohu, krome tech co jeste neprislu o date ze? ;-), protoze tim double zapisem kdyz by byl disk nacatej muze rovnou celej "odejit" ale kdyby misto toho se provedl 1 cele vykopirovani tak by "neodesel" (BTW: odeslo mi jen 1 SSD a to tak ze kdyz sem ho pripojil readonly tak slo vse vykopirovat, pokud se pripojil normalne i pro zapis, tak zmizel ze sbernice vykopnut jadrem)

[pepa novak]

použiť ZFS a raz za čas použiť scrub

[bmn]

Ze novsie SSD disky hniju je fakt https://forum.pctuning.cz/viewtopic.php?t=295770

badblocks pomoze ale iba docasne. ono to za par mesiacov vyhnije zase. takze by som to fakt videl na pouzitie btrfs/ZFS a periodicky scrub. inak na obcerstvenie tiez pomaha "btrfs balance" to ma na rozdiel od badblocks vyhodu ze to prepise iba realne data.

[Jan Fikar]

ten pctuning.cz je tochu pofidérní 

btrfs balance nepřepíše všechna data, jen ta, co nejsou rovnoměrně rozložena na RAIDu. Takže tady se nehodí

[Honza1Ubuntu]

Na SSD vydrzi data bez napajeni - pripojeni ke zdroji tak kratce ? To jsem vubec nevedel. A pritom je to pomerne zasadni informace pri ukladani dat na extrerni disk. U plotnoveho disku jsem data v pohode precetl i po 3 letech. Ale odezva disku vypadala uz pomalejsi.

Na kontrolu disku pouzivam prikaz (nedela zadne zapisy, opravy, pouze test, bezpecny mod):

Kód: [Vybrat]

badblocks -sv /dev/sdX

Tim by se mely zkontrolovat sektory na disku. Ale druha otazka je, jestli data stale 100 % odpovidaji realite. U 7zip archivu se da provest kontrola, to i rekurzivne, kdyz jsou archivy ve slozkach, podslozkach (ale musi byt v kontrolovane slosce jen archivy):

Kód: [Vybrat]

7z t Soubor_Nebo_Slozka

Kontrola kontrolnich souctu pak lze provest na vsechny soubory (kontroluje se skutecne, zda souhlasi obah, datum vzniku, posledni zmeny ted nehraje roli), vytvoreni txt souboru s kontrolnimi soucty (prikaz treba individualne nastavit):

Kód: [Vybrat]

sha 256sum Soubor >> MIstoTextaku/KontrolniSoucty.txt

Obcas ssd v Ubuntu blbnou, i se mi prepnul systemovy disk do read-only po nejakem chybnem sektoru. S novymi SSD si ne vzdy Linux rozumu.

Riziko je i zapisu spatnych dat, s tim ze se to bezchybne tvari. Kontrolni soucty se pouzivaji vzdy, ale jednou za radove nekolik stovek TB se objevi chyba v zapisu dat na disk, zmeni se jeden bit. U filmu-fotky je to samozrejme v podstate jedno, u programu a databaze to muze byt pomerne problem.

[Vrozkrokkop Kopalsson]

Kdysi na nějakém školení někdo povídal, že jak se zmenšují polovodičové struktury v integrovaných obvodech, stoupá nebezpečí, že částice kosmického záření co proletí polovodičem může přepsat nějaký bit. Jak moc je to pravda....