HDD - neizbežne napake pri branju (URE)

Že dolgo velja prepričanje oziroma ideja, da je po okoli 12 terabajtih prebranih podatkov z HDD napaka pri branju neizbežna (URE - unrecoverable read error AKA bye-bye my data). (viri spodaj)

Zanima me mnenje in izkušnje slotekovcev. V smislu:
- tak je
- neumnost
- moment, da preverim
- kaj drugega


http://www.zdnet.com/article/why-raid-5...
http://www.smbitjournal.com/2012/05/whe...
Oziroma celi kup: https://www.google.si/search?q=12tb+ure

PS: Je komu leta 2009 nehal delovati RAID-5? Ste prešli prej na kaj drugega?

Že RAID 6 recimo, kjer imaš pač dva redundančna diska, je čisto OK za tak primer. Tudi ne razumem čisto, zakaj taka panika. Da pri RAID 5 ostaneš brez podatkov morata sovpasti dva dogodka, izpad enega diska in prisoten URE na enem od presotalih diskov v arrayu, ko delaš rebuild, kar pa konec koncev ni nič drugega kot izpad drugega diska med operacijo rebuilda, česar RAID 5 pač ne pokriva. Poleg tega bo večina kontrolerjev lahko vsaj delno obnovila tak okvarjen RAID in boš, razen zelo izjemoma, izgubil le tisti del, ki je okvarjen (torej določeno datoteko), ne pa kar vsega.

Vsekakor pa drži, da RAID 5 že dolgo ni primeren za diskovne arraye z velikimi kapacitetami (v TB), pa naj gre za veliko število majhnih diskov ali pa za majhno število zelo velikih diskov. Sploh pri enterprise rešitvah. Še vedno pa dela čisto OK za arraye do 6 ali 7 diskov z nekje do 1 TB na disk.

Neumnost. Kolikokrat sem že skorigiral tak raid, tudi ne pomnim več.

Če bi bilo to res kar praviš, bi ga zgubil enkrat letno.

Ja, RAID ne ve ničesar o datotekah, ampak ti imaš možnost prečekirati ali je določen sektor v datoteki ali v prostem prostoru.

Kar se teh "naprednejših rešitev" tiče, sem se jih nagledal.

Koliko folka je modrovalo o BTRFS, nato pa je sledil plaz sesutij in prav debilnih zapletov.

Kar se ZFS-a tiče, afaik še vedno ni prosto v kernelu in GPL-x izvedba še vedno ne dohaja originala, pa tudi verjetno ni za vse potrebe, drugače bi bil default FS povsod.

MrStein> Zanima me mnenje in izkušnje slotekovcev. V smislu:
MrStein> - tak je
MrStein> - neumnost
MrStein> - moment, da preverim
MrStein> - kaj drugega

Definitivno se zgodi, ampak tega ne moreš opaziti.

Unilseptij> Že RAID 6 recimo, kjer imaš pač dva redundančna diska, je čisto OK za tak primer.

Ne, ni, ker praktično nobena implementacija RAID-6 ne preverja integritete podatkov.

Brane22> Neumnost, če mene vprašaš.

Kako pa preverjaš, če so vrnjeni biti enaki kot so bili zapisani?

jype je 3. jan 2017 ob 01:35 izjavil:

Kako pa preverjaš, če so vrnjeni biti enaki kot so bili zapisani?

Če misliš to za potrebe testa, folk je napisal simpl rutine, ki to omogočajo.

Če recimo odprem disk device in se sam s seboj zmenim, da vpišem v vsak sektor zaporedno številko sektorja, ki jo potem permutirano ponavljam skupaj z zaporedno številko recimo long longa znotraj sektorja, hasha ne rabim.

Folk je delal torture teste take in drugačne in je zlahka prišel čez to mejo.

@Brane22

Sem videl loge od enega konkretenga storage sistemal, mislim da emc vmax, ki ima end to end preverjanje integritete pa je bilo vsak mesec nekaj zanannih in popravljenih napak.

Pa ne URE, v tem primeru se pač sektorja ni dalo prebrati in ga raid kontroler pač prebere iz drugega diska.
Šlo se je za napake, ko je sektor sicer uspešno prebran ampak je vrednost drugačna od tiste zapisane. Torej se je en bit flipnil. Sistem to ugotovi preko dodatnih checksumov na FS-ju in potem rekunstrira pravilno vrednost in tudi popravi zapis na disku.
In takih napak je bilo vsak mesec ene par.
Zdej če se ti flipne en bit v neki sliki ali spiratiziranem filmu verjetno ni panike. Kak piksel bo malo čudne barve ali pa kak frejm videa malo zatrokira.
Če pa imaš gor neke pomebne podatke je pa to lahko precej drugače.

Za običajne uporabnike dosegljive rešitve, ki zagotavljajo end to end integriteto so kolikor vem:
ZFS
BTRFS
REFS

Mislim da je od teh ZFS še najbol preverjena rešitev. In pa rabiš tudi ECC, če ne se ti še vedno lahko pokvari kaj v ram-u.
Je pa verjetno vprašanje koliko je to zares težava za domače uporabnike.

Sej verjetno je isto za BTRFS in REFS. Povsod se mora računati hashe in preverjati checksume so vsi ti podatki vsaj nekaj časa v RAM-u.

BTRFS je beta (lepše povedano: v razvoju)

ReFS uporablja hash le če je na Storage Spaces (vsaj po defoltu, verjetno se da vklopiti tudi za "navadne" volume-je).

Microsoft je naredil test in prebral 700 TB brez napak (potem so test ustavili).

Po mojem je razvoje tega mita takšne:
To idejo so prvi omenili v znanstvenem članku o RAID, ampak so takoj dodali, da ni definirano, kaj točno URE tista številka pomeni. PREDPOSTAVLJALI so, da pomeni "v povprečju ena napaka na 12TB prebranih podatkov". Takrat so diski bili veliki 2GB s prenosi 10 MB/s in je to bilo zanemarljivo.
Potem pa so tisti stavek začeli ljudje ponavljati in je mit postal... legenda.
Redkokateremu pa se je posvetilo "hej, saj to trditev lahko preprosto preverim v nekaj urah". Ali minutah, če obstoječe loge preveri.

(viri pozneje, ker so na drugem PC)

Še en zanimiv članek:
Why RAID-5 Stops Working in 2009 - Not Necessarily
(po komentarjih sodeč nekje iz leta 2012, datum samega članka ne najdem)

Citiram prvo poglavje, poudarki moji:

Suppose you were to run a burn in test on a brand new Seagate 3TB SATA drive, writing 3TB and then reading it back to confirm the data. Our standards are such that if a drive fails during 5 cycles we won't ship it. Luckily, all 20 of 20 drives we tested last night passed. In fact, most of the 3TB drives we test every week passed this test. Why is that a big deal? Because there is a calculation floating around out there that shows when reading a full 3TB drive there is a 21.3% chance of getting an unrecoverable read error. Clearly the commonly used probability equation isn't modeling reality.

'If data does not fit the theory then the theory is wrong.' - bi lahko rekli.

Absurdno nizka ne-ničelna številka? Za vse praktične namene "shranjevanja podatkov" je edina sprejemljiva številka 0. Sicer lahko redefiniraš "shranjevanje podatkov" na nekaj podobnega, kot to počnejo naši možgani - zelo slaba primerjava bi bil mp3 @ 32kBps. Lossy as f... ;) Če mi dovolite malo filozofiranja - pozabljanje je nekaj, kar enostavno moramo naučiti vse naše data storage sisteme, problem je samo, ker je pozabljanje vezano na tip podatkov in ga je torej težko do nemogoče implementirati kot nekaj splošnega. Mogoče nekoč ... trenutno je lažje preganjat bitrot in kupovat petabajte vsake pol leta.

l0g1t3ch je 3. jan 2017 ob 23:47 izjavil:

V tistem članku je avtor prišel do sledečega zaključka (po spominu):
- če v sektorju flipne vsaj 1 in manj od nekega n, bitov (kjer je n neka zgornja meja koliko jih algoritem lahko popravi) -> ECC od diska ga ujame in popravi, kar se tiče raida kot da s ni nič zgodilo, disk je vrnil podatek
- če flipne več kot n, bitov imamo mejo m bitov (m>n) kjer algoritem zazna da je bila napaka in da je sektor nepravilen -> disk javi URE, raid potem prebere isti sektor iz drugega diska in popravi še sektor na prvem

Tako, da je bil kočni zaključek da bit rot-a na samih diskih ni oz je verjetnost neka absurdno nizka številka, za vse praktične pomene enaka 0.

Saj to ni nikakrsen zakljucek, to so samo dejstva (tako pac algoritem deluje, torej do neke meje napako lahko odpravi, do neke visje meje pa je sicer ne more popraviti, jo pa lahko zazna, nad to mejo pa ne more zanesljivo narediti nicesar oziroma lahko nevede naredi se vecje sranje kot je ze bilo).

Ti potem iz tega vleces zakljucke (tudi v postu nizje) in navajas neke stevilke, za ketere ugibam, da si si jih izmislil.

Seveda bit rot pri diskih je problem, sicer bi bil edini izvor napak sele za bralno glavo (npr. zaradi kozmicnega sevanja itd.). Ce ga ne bi bilo, ne bi bilo potrebe po ECC shemi za zapis podatkov, ampak bi ECC uporabljali izkljucno na prenosnih poteh (kabli, kontroler), po katerih se prebrani podatki pretakajo.

l0g1t3ch je 4. jan 2017 ob 10:13 izjavil:

@Ahim.

Ne vlečem jaz nobenih zaključkov.
Tisti zaključki so bili na koncu članka in tudi številke so od tam (po spominu, gre se predvsem za velikostni red). Zaključek avtorja je bil ravno to, da je verjetnost dogodka da ECC ne bi mogel popraviti oz. vsaj zaznati in javiti napake praktično nič. Posledično da je vsaka skrb za bit rot na diskih odveč.
Ponavljam, to je zgolj en članek in mnenje tistega avtorja.

Imaš seveda tudi povsem drugačne, ki pravijo da je ECC na diskih ni dovolj in da se bit rot dogaja.
http://blog.fosketts.net/2014/12/19/big...

Bom se enkrat, ker ocitno prvic nisem bil dovolj jasen:

Kar je napisal avtor, so zgolj dejstva - tako pac delujejo ECC algoritmi, nic novega.

Ti si iz tega vlekel zakljucke v postu nizje v temi (kar mislim, da sem napisal?), zdaj si pa zraven privlekel se "velikostni red". Koliko pa je en velikostni red, ko zacnes operirati z intervali ("In tam navedena številka je bila 10^-30 ali pa 10^-40")?

In ce je "tako majhna da je za realne namene lahko 0" (kar je bil tvoj zakljucek), cemu potem sploh potreba po ECC?

Ahim je 4. jan 2017 ob 18:13 izjavil:

l0g1t3ch je 4. jan 2017 ob 10:13 izjavil:

@Ahim.

Ne vlečem jaz nobenih zaključkov.
Tisti zaključki so bili na koncu članka in tudi številke so od tam (po spominu, gre se predvsem za velikostni red). Zaključek avtorja je bil ravno to, da je verjetnost dogodka da ECC ne bi mogel popraviti oz. vsaj zaznati in javiti napake praktično nič. Posledično da je vsaka skrb za bit rot na diskih odveč.
Ponavljam, to je zgolj en članek in mnenje tistega avtorja.

Imaš seveda tudi povsem drugačne, ki pravijo da je ECC na diskih ni dovolj in da se bit rot dogaja.
http://blog.fosketts.net/2014/12/19/big...

Bom se enkrat, ker ocitno prvic nisem bil dovolj jasen:

Kar je napisal avtor, so zgolj dejstva - tako pac delujejo ECC algoritmi, nic novega.

Ti si iz tega vlekel zakljucke v postu nizje v temi (kar mislim, da sem napisal?), zdaj si pa zraven privlekel se "velikostni red". Koliko pa je en velikostni red, ko zacnes operirati z intervali ("In tam navedena številka je bila 10^-30 ali pa 10^-40")?

In ce je "tako majhna da je za realne namene lahko 0" (kar je bil tvoj zakljucek), cemu potem sploh potreba po ECC?

Mislim da bom poskusil še enkrat in zadnjič. Lepo po točkah:
1. Nisem vlekel nobenih zaključkov, po spominu sem napisal kar je avtor članka zaključil.
2. Vse je pisano po spominu, ker članka sedaj ne najdem. Bi bil vesel če bi ga.
3. Omenjena verjetnost je verjetnost dogodka da ECC zataji. Torej da disk kljub internemu ECC-ju vrne drugačen niz bit-ov iz prebranega sektorja, kot pa je bil gor zapisan.
Ker bo ECC ali popravil napako če bo lahko ali pa vsaj javil napako. Tretja opcija da se sektor sicer prebere ampak so biti na njem tako "napačni" da ECC tega nikakor ne zazna je tista izjemno mala možnost za katero sem napisal številke.
4. ja velikostni red sem pa res napisal jaz, ker ne najdem boljšega izraza. Originalni avtor je napisal eno samo številko ampak meni se zdi isti K*** ali je bila 0^-30 ali pa 10^-40. Oboje je tako majhno da je za vse praktične namene enako 0. In to zadnje je bila sklepna misel članka.

In potem sem dodal še en link kjer pa drug človek pa piše drugače, da ECC-ju od samega diska ne gre zaupati.
Zdej pa se vsak sam odloči komu verjet.
Jaz se v stvari nisem poglobil toliko da bi dal prav enemu ali drugemu.

Unilseptij je 4. jan 2017 ob 22:26 izjavil:

Odkod potem ocene za URE med 10^-14 in 10^-15, ki jih podajajo sami proizvajalci?

https://www.wdc.com/content/dam/wdc/web...

Jaz sem v člankih videl dve različni tolmačenji URE in sicer kot verjetnost za:
1. napako da javi disk da sektorja ni mogel prebrati pa ni važen razlog ali je to neberljiv sektor ali pa interni ECC zazna napako na prebranih podatkih, ki je ni uspel popravit
2. napako da je med biti ki jih je disk vrnil en napačen

Če velja prvo, potem te raid reši, če velja drugo, potem imaš silent data corruption in te reši samo ZFS in podobni FS-ji.

MrStein je 3. jan 2017 ob 17:19 izjavil:

(viri pozneje, ker so na drugem PC)

Evo:

Chen et al, RAID: High-Performance, Reliable Secondary Storage (1994)
stran 160:

Currently, most disks cite uncor-
rectable bit error rates of one error in
10^14 bits read. Unfortunately, the exact
interpretation of what is meant by an
uncorrectable bit error is unclear.

Jim Gray, Catharine van Ingen, Microsoft Research:
Empirical Measurements of Disk Failure Rates and Error Rates 2005

The SATA advertised bit error rate of one error in 10 terabytes is frightening. We moved 2 PB through low-cost hardware and saw five disk read error events

5 napak, po mitu pi jih moralo biti 200.

Thus far, the System 1 read-only test has read 756 TB and seen no errors.

The drive specifications of UER=10^-14 suggest we should have seen 112 read errors.

Dejansko jih je bilo 3 (in še dva, ki pa sta uspela po retry-u)

Komentar na blog "Does RAID 6 stop working in 2019?" (2010)
http://storagemojo.com/2010/02/27/does-...
Citat:
"The population included several hundred drives across several build lots and capacity points and saw and actual URE rate greater than 10^18." - Ben March 1, 2010 at 8:07 am


Še nekaj o sorodni temu LSE:
Understanding latent sector errors and how to protect against them
Povzetek: LSE se zgodijo nepričakovano, ponavadi kot gruča in posledica enega dogodka.