Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
a coz takhle jeste nejakou cest disku prepisovat dokud se natvrdo neprepne do read only rezimu?
Nac cekat? Likvidovat dale.
prvnich 5GB naplnit daty a ty nechat byt
Zbyle misto dal nicit.
Za tyden dva naplnit dalsich 5GB a nechat byt, zbytek dal nicit. atd atd
Az takto napnite cely disk pak se muze nechat ulezet delsi dobu. Pak se da zjistit, ktery 5GB usek uz neprezil a podle toho odhadnout kolik to vydrzelo.
Pokud budete delat velky prestavky na test vydrze casto tak se konce nemusime ani dockat :)
Protože když prvních 5GB naplníš daty a zbylé přepisuješ, tak se o schopnosti buněk udržet hodnotu NIC NEDOZVÍŠ. Disk totiž automaticky přesouvá statická data tak, aby docházelo k co nejmenšímu rozdílu v počtu přepisů u jednotlivých buněk.
PS: Po přečtení diskuze už chápu, proč anketa vypadá jak vypadá. Polovina lidí ani tady na "deep in IT" nechápe, jak SSD funguje.
Tri pripominky
1. Presouva data i do papirove mrtvych bunek? Data o kterych vi ze se nemeni a musi vydrzet dlouho. Nebo je necha v bunkach, ktere jsou teprve na hrane, ale maji vetsi sanci udrzet dlouhodobou informaci? Pouziva radic jinou logiku na zdravy a mrtvy disk? To tim muzes zjistit
2. V pripade ze to presouva, tak se nepresouvaji nejak nesmyslne casto (tim by vice zkracovali zivotnost - tj presouvaji az pri vetsich rozdilech). Takze drzenim staticke kontrolovatelne casti, testujes schopnost udrzet informaci a pokud ty data pravidelne testujes tak i hned zjistis kdy disk odesel (bud diky neshopnosti udrzet data, nebo automatickym presunem do vadnych bunek)
3. SSD se nepouzivaji jako odkladiste dat do supliku. Lidi spis zajima jak dlouho jim disk vydrzi, jak dlouho po skonceni teoreticke doby zivota ho muzou pouzivat, bez toho aby se jim poskodil system (staticka data). A behem te doby ho maji pusteny a pouzivaji ho. Jestli ma radic nejaky triky jak obejit zkracenou pamet bunek, tim lepe. To by mel test zjistit - realne pouzivani. Ne jak dlouho to udrzi data v supliku.
ad 1) způsob určování "mrtvých" buněk nevím, ale četl jsem, že se použitelnost zjišťuje hned při zápisu (tedy buď se povede a ta data tam disk nechá, nebo je zapíše jinam). Pro další debatu klidně předpokládejme, že disk nikdy neuloží data do vadných buněk.
ad 2) + 3) Pokud by se na disk dále zapisovalo cca 5GB denně (tedy typická hodnota trochu náročného užití), pak bys měl pravdu. Při konstantním zápisu se ale na disk dostávají řádově terabajty denně. Tzn o tři řády více. Tzn statická data se přesouvají cca 1000x častěji než při běžném užití, takže stačí aby byly buňky schopné udržet data 1000x kratší dobu. Tedy NIC RELEVANTNÍHO ohledně retence tímto způsobem neotestuješ.
aspoň rok, když už mi nejde hlasovat
Sak to cte 50mb/s ne? Za 10 minut je to zkontrolovane, proc tu kontrolu automaticky nepustit kazdy den?
Jenže při tom každodenním čtení se může stát, že SSD objeví nějaký blok, který je "jentaktak", teď ještě přečíst jde, ale za dva dny už by nešel, a přesune ho proto jinam. Samozřejmě jde o to, jestli je ještě kam, nikdo z nás asi přesně neví co znamená ten indikovaný konec životnosti.
P.S.: Neodpustím si rýpnutí, 50 milibitů za sekundu není zrovna fofr :))
„per to do mě, ať je po mě!“ +1 ;)
Hlavne ale začnite používať pre kontrolu integrity dát niečo spoľahlivejšie ako obyčajné CRC, napríklad MD5 alebo SHA-1 prípadne SHA-256. CRC vám symetrické chyby na úrovni zmeny bitov neodhalí, t.j. ak jeden bit zmení stav 0->1 a zároveň iný bit sa zmení z 1->0 tak CRC bude stále rovnaké :(
Těch souborů jsou tam mraky a věřím, že jestli by to zachybovalo, tak nezachybuje jen jeden bit, nebo dva, ale víc tak, že se něco najde. Krom toho tipuju, že když odejde jeden fyzický bit v čipu, spíše než změnou dat se to projeví nečitelností, aspoň u SSD to tak očekávám (u obyčejné flashky už jsem čitelnost, avšak chybovost v datech již zažil).
Funkce md5 už je nějaký pátek mrtvá a sha-1 už to má taky za pár. To nepíšu proto, že bych chtěl být za každou cenu hnidopich, ale proto, že se stále setkávám s novými projekty, které to používají. Prosím, opravdu ty funkce ani nezmiňujte, ať prostě umřou. Jde o bezpečnost.
A prosím neodpovídejte mi, že na "kontrolu integrity" jsou ještě dobré. Nejsou. Jednou jsou ty funkce kryptograficky prolomené a to prostě pro jejich zamítnutí stačí.
Ano to na zamietnutie staci,ale v novom projekte kde je podstatna aj bezpecnost(asi vacsina)Ale urcite nie su bezpredmetne,len pre rychlu kontrolu checksumu (tvoj pc nespravi pri prenose tolko chyb aby boli zhodny checksum)
Tiez sa cudujem, preco chcu data kontrolovat s CRC. Ved ide o autenticitu dat, kde CRC neni buhvi co. Hashovacie funkcie samozrejme zo svojej podstaty tiez trpia neduhom ovela mensieho poctu kombinacii v hash stringu ako v testovacom stringu (zdaleka sa teda nejedna o zobrazenie zvane bijekcia). Avsak hash funkcie su lepsie prisposobene ku kontrole autentickosti. Kompromisom moze byt sice uz roky slaba a prelomena MD5, pripadne Shamir family staci aj SHA1 (dnes tiez nie bezpecna, ale na tieto ucely staci). Nema to sluzit v certifikate na overenie kompetentcii na zacatie vojny.
Vypocet hashu aj pre 1 GB subor netrva viac ako par desiatok sekund. Ak kontrolovat data, tak poriadne.
Inak zaujimave je, ze valna cast certifikatov vyuziva hash funckiu MD5, pripadne SHA1. To este nikto z kompetentnych nezistil, ze to je out of date? Potom sa stane toto:
http://www.dsl.sk/article.php?article=13544
http://www.dsl.sk/article.php?article=6801
http://www.dsl.sk/article.php?article=7609
http://www.dsl.sk/article.php?article=10173
+ diskusie
Na záver: Dejte mi tři soubory a já vám zítra vrátím libovolné tři jiné, se stejnou (MD5) haší," říká na nejznámější český kryptolog Vlastimil Klíma.
"Inak zaujimave je, ze valna cast certifikatov vyuziva hash funckiu MD5, pripadne SHA1."
No jo no. Já už více než dva roky dělám CRT výhradně s hashovací fcí rodiny SHA-2 (konkrétně sha-256), v Evropě se už nic menšího používat nesmí (pro kvalifikované certifikáty).
Osvěta je v tomto zdá se velmi málo učinná. O MD5 se to ví už od roku 1996 (v roce 2004 už byla prolomená definitivně) a i dnes, 17 (resp 9) let po té ji stále ještě někdo chce použít.
mám takový pocit, že u el. podpisu se používá SHA1. Tedy myslím, že tohle jsem tam při nedávném obnovování viděl.
První test za týden, druhý po dalších dvou, třetí po dalších čtyřech atd., takové "exponenciální ustupování" ;)
Mno, kdyby to bylo exponenciální, tak to bysme si moc článků s dalšíma informacema o stavu SSD už asi neužili ;-). Já bych to nechal +- lineárně.
10 let, krátkodobé skladování bude O.K.
To je fakt, ale to už by nám pak bylo asi poněkud na pendrek... spíš tomu nějak prostě "pomoct", něco jako umělý stárnutí - třebas tomu SSD trošku zatopit (když už tady skoro máme to léto, tak by se taková možnosti docela nabízela ;-).
Já bych navrhoval tam nahrát pár giga kontrolních souborů a zbytek mučit dokud se nepřepne do read only. Ten kontrolní vzorek tam pak zůstane a může se nechat ležet roky.
nebo ho rozdělit
na jednu část nahrát statická data a zbytek umučit k smrti
Teď když je papírově mrtvý, tak celý naplnit daty pro data retention test a nechat týden uležet, aby se zjistilo, že pokud hlásí papírový konec, tak jestli si pamatuje. To je jediný logický úkon, který lze učinit, aby test k něčemu byl. Když si pamatuje, tak zjistíme, že při papírovém ohlášení konce je SSD bezpečně funkční, když Intel mu dával záruku na 36TB a je na 190TB. To samé se udělalo u 40GB retention data test, tak je bezpředmětné se ptát co si kdo přeje s ním dále dělat. Myslím, že i WIFT čekal co udělá disk, až dosáhne Wear out idicator 1 a neudělat nyní týdenní test data retention může jen naprostý HW ignorant.
Nesmyslné příspěvky diskutujících, co nemají šajnu o tom jak SSD funguje a to zejména za řadičem ignorovat. A pak už si s diskem dělejte co chcete.
Tiez som za moznost nechat to lezat nejaky tyzden.
Každé 4 týdny přečíst celý obsah a porovnat výchozí kontrolní součty na sektorech (myslím, že i md5 pro tento účel v pohodě vyhoví, flash disk není zákeřný útočník). Zaznamenávat počet vadných sektorů a u vadných sektorů specielně zaznamenávat i počet vadných bytů, aby bylo vidět, jak moc "se chyby čipem rozlézají".
Výsledkem by měl být seznam vadných LBA bloků pro každé čtení + počty bytů pro každý blok, nebo 0.
Bylo by i zajímavé porovnat - jestli se vadnými stávají častěji 1 na 0, nebo naopak. Nebo jestli opakované čtení vadného bloku poskytuje stejná chybná data, nebo náhodná.
Existence filesystému je zcela nezajímavá. Obsah může být klidně něco jako "digitální bílý šum".
Bohužel - obávám se - že výsledek nebude, protože i takto "ošoupaná" flash udrží data déle, než budete/budeme ochotni čekat. Což ovšem pořád neznamená, že je spolehlivá, prostě jen nemáme dost vzorků a dost času.
>porovnat výchozí kontrolní součty na sektorech
Jenze to SSD nic jako sektory nema. To, ze ted sektor cislo 1 ukazuje nekam na zacatek, vubec neznamena, ze za 2h nebude ukazovat na protilehly konec.
Veskera adresace vne SSD je virtualni. Nevim o zadnem SSD, ktere by umoznovalo primy pristup na jedno konkretni misto (to by se pak v linux kernelu krasne ladil novy SSD filesystem, ktery by pak nektery vyrobce klidne pouzil jako firmware...:) ).
Já vím, ale když nic na SSD nezapisuje, tak se nic nikam nepřemístí. Nebo ano?
Nevím jak ve Windows, ale Linux zapsat nemusí, dokud nepřipojím svazek i pro zápis, nebo na něj nezapisuju data přímo přes /dev (neuvažuju použití desktopové instalace s automounterem). A zápis by znevěrohodnil test, ne? Protože přemístěný sektor je vlastně nově zapsaný = obnoví se náboj v buňkách (ovlivní náboj i čtení?).
A pokud se nic nezapíše, tak je jedno, že adresace je virtuální (překládá se přes nějakou tabulku). Sektor označený nějakým čislem zůstává pořád ten samý a měl by se číst stále ze stejných buněk.
To, že z LBA adres nepoznám skutečnou polohu buňek na čipu mne nemusí trápit. Možná trochu zajímá, za určitých okolností, ale nevadí. Ostatně i HDD umí relokovat sektory a jejich LBA adresa nemusí přesně určovat polohu na médiu.
Jenže problém je, že ve skutečnosti nevíš, co se vevnitř děje a co se kam fyzicky zapisuje. Možná se to dá nějak odhadnout podle chování a možná by to šlo nějak otestovat, ale asi by to nebylo úplně jednoduché? No každopádně WIFT bude určitě o tom vědět daleko víc.
Co se týče toho "nezasahování do stavu SSD" čtením - tak to je taky otázka, jak to je. Teoreticky se čtením nic nezmění, ale pokud by si SSD analyzoval "čerstvost" buněk, tak by se mohlo stát, že (jak tady už napsal někdo v diskuzi) by to už někde bylo na hraně, ale data by šlo přečíst, ale pro jistotu by je hned nato SSD přesunul jinam - byť by se z hlediska OS jednalo o pouhé čtení. Ono vůbec celkově může být v mnoha ohledech SSD oproti "pitomému" HDD celkem černá skříňka.
Dost bych se divil, kdyby se něco v rozumném čase projevilo. Navíc nějaká jednoduché bitové chyby řadič umí opravit.
Ja bych to zkousel jednou tydne precist (a rovnou to tahat ze ssd max rychlosti pokud to jde a pak rychle vypnout). Ono se totiz muze stat, ze vyprchaji systemove bunky a nenabehne SSD vubec... a na druhou stranu si SSD muze trocha uklidit pokud ho nechate necinne...
Dle datasheetu Intelu k jistemu modelu je po prekroceni limitu garantovana doba udrzeni dat 3 mesice.
Melo by to byt po 10 letech, ale na to nikdo nema naladu.
Spis bude lepsi zacit s prepisem(s okamzitou CRC kontrolou) hned a jet az do vyskytu prvni chyby.
A co ti pomůže do výskytu první chyby zápisu? Akorát zjistíš, kdy udělal disk první chybu, ale co když si před chvílí zapsaná data už na jiném místě nepamatuje? Udělat týdenní data test retention opakuji je v této fázi nezbytný a přes to vlak nejede, protože u paměťového média jak sám název napovídá je nejdůležitější vlastností si pamatovat.
Na kontrolu zápisu CRC ti uvedu příklad. Mám baterku na kliku, kterou nabíjím akumulátor, když si chci jednou do roka posvítit. Tedy nabiji trochu akumulátor (buňku NAND) a rozsvícením provedu kontrolu CRC. Test OK. Jenže za týden akumulátor ztratí náboj z těch pár otočení kliky a kontrola zapnutím CRC zjistí, že nesvítím. Takže ani okamžitá kontrola CRC toho moc z hlediska pamatování dat nezjistí. Akorát, že akumulátor nemůžu nabýt a to je docela už pozdě. Proto bych jako optimální viděl nechat zapsaná data týden odležet.
Flash bunky jsou vlastne kondenzatory a mazanim se zhorsuji izolacni vlastnosti dielektrika mezi elektrodami.
Chyba zapisu bude jasny dukaz o destrukci bunky. Vyrobce bude mit urcite nejakou rezervu poctu zapisu a jiny zpusob testovani by mohl trvat roky...
K cemu Ti bude kontrola po tydnu? to chces prepsat cely SSD a pak tyden pockat, zkontrolovat CRC a pokud budou CRC ok, zase prepsat cely SSD? Jak dlouho bys to chtel delat? rok, nebo dele?
Ve "zdrave" bunce by data mela byt citelna po 10 letech. Na takovy test nema nikdo cas a mozna by ho ani nikdo necetl. IMHO.
Jenže kondenzátor se vybíjí. To, že to přečteš ihned po zápisu neznamená, že to přečteš za týden, zítra, či dokonce za několik sekund. Pokud to buňka udrží jedinou sekundu, pak je způsob "zapsáno==přečteno => je to OK" úplně k ničemu.
Kontrola po týdnu tohle aspoň částečně řeší. Navíc nevím, proč po tom týdnu znovu celý SSD přepisovat, prostě tam necháš sušit ta samá data do další kontroly.
Prepisovat musim, protoze kdyz data nebudu prepisovat, muze se mi velice lehce stat, ze na prvni spatnou bunku budu cekat vice nez 10let...
Mozny kompromis vidim v tom, ze se SSH prepise cele treba 20x a necha tyden ulezet. Po tydnu se zkontroluje CRC. Pokud je CRC ok, zase se 20x prepise. A tak dale...
Jen nevim, jestli 20 prepisu dostatecne "zestarne" pametove bunky. Mozna jich bude potreba vice.
Provádět zápis do zablokování nebo do skonání. Poté udělat obraz disku (image v podobě bitové kopie) a ten kontrolovat pro sledování schopnosti výdrže udržení informace. Vznik chyby lze detekovat porovnáváním kontrolních kódů obrazů disků. Původní obraz disku je nutné uchovat, aby v okamžiku, kdy nastane degradace bylo možné zjišťovat % rozdílu a progresi nárůstu degradace... Tento princip vyžaduje uchovávat dva obrazy. Původní pro sledování % rozdílu a poslední chybný pro rychlou detekci nové chyby. Celkem se tedy musí pracovat se třemi soubory.
Ještě jedna poznámka ke sledování degradace. Na disku musí být ideálně jen taková data, která nemají hodnotu, ke které degradace směřuje, tj. kdyby např. buňka v absolutně "degradovaném" stavu vykazovala hodnotu 255, pak soubory nesmí obsahovat hodnotu 255, protože by nebylo možné detekovat chybu (ta by na dané buňce ani nemohla vzniknout).
Ta první část mi zní rozumně s tím, že mně bude pro jednoduchost stačit práce se dvěma soubory.
Ta druhá část bude horší. Jelikož nevím, jak se interpretuje buňka (bit) v degradovaném stavu (jestli jako 0, nebo 1), tak prostě budu muset risknout hrst náhodných dat a počítat s tím, že něco holt nebude moci odejít.
No, pokud to půjde a generátor to umožňuje, tak bych vynechal hodnoty 255 a 0, tím si pokryji oba konce... ano, je pravdou, že pak nastane případ z druhé strany, ale statisticky je lepší přijít o jeden bit než o celý bajt...
U dvou souborů bude nutné počítat počet změn z jednoho na druhý, ale jedna buňka se jistě změní vícekrát po sobě a ne vždy pokaždé. Zde je nutné mít alespoň originál a porovnávat nárůst počtu rozdílů, jenže se pak musí pokaždé kontrolovat celý disk...
Podle JEDEC musi consumer SSD udrzet data pri 25st.C jeste 12 mesicu po vycerpani deklarovaneho poctu cyklu erase-write. Enterprise SSD pouze tri mesice (predpoklada se okamzita vymena).
Intel 320 je intelem razen mezi consumer SSD.
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.