Intel RAID 5 Verification errors?

[Condor]

Postovanje forumasi!
Moze li mi neko sa sigurnoscu reci na sta se tacno odnose "verification errors" koje prijavi IRST softver (Intel Rapid Storage Technology, mislim da se nekad zvao Intel Matrix Storage Manager, za starije chipset-e) za Intelov RAID 5 (niz na ICH10R)?

Inace, ono sto sam i sam skontao je da se ove greske pojave (naravno) nakon verifikacije niza, a verifikacija se automatski radi kad se sistem neocekivano sleši (nestabilan overclock, nasilno gasenje i sl.). Pretpostavljam (ali samo pretpostavljam) da se te greske odnose na broj gresaka sa parity-jem niza, a ono sto me zapravo zanima je da li iste uticu na konzistentnost podataka na bilo koji nacin?

Sve sto pronadjoh na ovu temu (IRST help, Google) vrti se oko nacina kako verifikovati niz i izvrsiti repair, ali ne pronadjoh info sta tacno ove greske predstavljaju i kako uticu na podatke na disku?!

 

[alfaunits]

Ne postoji garancija oko podataka u tom slucaju, niti mogucnost da se utvrdi tacnost istih. Da bi to bilo moguce, neophodan bi bio double-parity (kao sto RAID6 ima recimo), ali pod uslovom da samo jedan parity otkaze, a drugi je validan!

Tipicno, ono sto se desi je da se podaci upisu kako treba, dok parity se kalkulise i dalje u memoriji, i sistem padne, pa dodje do nekonzistentnog stanja.
Iskreno ne znam koliko podataka IRST drzi u memoriji tokom generisanja parity-a, pa ne mogu da tvrdim koliko gresaka moze nastati na ovaj nacin, pri JEDNOM crashu.

Bottom line: bez double-parity ne mozes biti siguran u tacnost podataka. Sem ukoliko se neki potpisan executable ne nalazi na tim lokacijama, pa se on moze koristiti kao provera, ili ako je neki dokument pa rucno proveris.

Samo da napomenem, vredi znati, nijedan RAID kontroler (softverski ili hardverski, nebitno) ne radi proveru podataka tokom citanja, ili pisanja. Dakle, on pretpostavlja da su podaci u redu, i cita samo podatke (i za citanje i za upis, kada je potrebno citanje ostalih podataka za promenu parity-a), dok parity samo menja tokom upisa. Provera se vrsi iskljucivo rucno, ili u slucaju pada sistema automatski.
Razlog je ocigledan - da se radi provera tokom citanja/pisanja, performanse bi bile komicno male 😉

Neki IBMovi kontroleri, barem su mi tako rekli, mogu da se podese da rade ovu proveru, ali sem njih, do sada nijedan RAID kontroler nisam video da ima cak i mogucnost da se podesi, a po defaultu nijedan ne radi.

 

[Condor]

Alfa, po obicaju si detaljan i jasan, veliko hvala!

Znaci, ukratko, ovi verification errors se bukvalno odnose na pogresan parity za zapisani podatak (1 na 1, tj. koliko je podataka u nekonzistentnom stanju, toliko gresaka prijavi), pri cemu se ne moze sa sigurnoscu znati da li se promijenio (ostetio) podatak ili kontroler nije stigao da upise novi parity za azurirani/upisani podatak (prilikom iznenadne "havarije")!?

 

[alfaunits]

Yep.

 

[Condor]

Samo jos jedno pitanje (izvinjavam se sto sam lijen da guglam) - je li se pojedinacan parity racuna na nivou fajla ili na nivou bloka podataka fiksne velicine koji se konfigurise za RAID5 (ako se ne varam, mislim da se zove stripe size)? Logican mi je ovaj drugi scenario... Ili su stvari malo komplikovanije od toga?!

 

[alfaunits]

Po stripe-u, tj. za blok stripe-ova. (broj diskova minus jedan, puta stripe size je velicina za koju se racuna parity, a parity je velicine jednog stripe-a). za RAID5. Za RAID6 je minus dva umesto minus jedan.
Kada se racuna zavisi od konkretnog kontrolera i polise kesiranja.

 

[Condor]

Ziv bio, hvala puno (ustedio si mi vrijeme)!

 

[duksa88]

ako smem ja da se ubacim, prvo radi backup pa onda radi proveru.
Kao sto rece alfa, on lako izracuna parity koji ne treba..

 

[Condor]

Hvala na interesovanju, duksa...
Ali nisam siguran na sta si tacno mislio (mozda mi je nesto promakelo)!?
Pada mi na pamet situacija kad je podatak na jednom disku ostecen, pa iako je parity na trecem disku dobar, verifikacija ce ga pogresno sracunati (na osnovu korumpiranog sadrzaja) i prepisati pri prvom sledece pokretanju... Ali ovdje ne vidim korist od prethodnog backup-a, jer cu svakako backup-ovati korumpirane podatke, zar ne?! Ili si mislio na nesto drugo?

P.S. Backup podataka svakako radim povremeno, a verifikaciju RAID niza prakticno nikad, bar ne manuelno... Nedavno se verifikacija pokrenula automatski kad sam zeznuo masinu za pretjeranim overclock-om (pronadjena su dva verification error-a), a s obzirom da mi se slicno desilo i prije 3-4 mjeseca iz istog razloga (OC, cackanje oko RAM-a) kada sam imao cini mi se 7-8 ovih verification error-a, odlucio sam da se raspitam na forumu.

P.S.2 Sistem mi uopste nije na RAID nizu, vec zaseban SSD - cudno mi je sto se zeznu podaci, tj. parity na RAID-u gdje mi je prakticno samo storage, pri cemu nista licno ne pisem po RAID disku u trenutku "havarije" (mora da sam Win7 stalno nesto piskara i brljavi, to mi je jedino logicno)?!

 

[duksa88]

ja se plasim situacija u kojima su diskovi ne sinhronizovani, i akcija koje ljudi tada rade.
Tipa otkaze jedan disk, pa se drugi stavi novi...ili jedan disk ispadne iz nekog razloga, pa se reinicijalizuje sam iz nekog drugog.
Tipa prasina kontakt ko zna. U zavisnosti od toga sta se desilo zavisi i koliko traje proces rebuilda a da klijent nije ni primetio.
Stoga se plasim sta se desava kada se radi verifikacija i koje se greske ispravljaju. Nekako kad je uradjen backup , sigurniji sam.
Ipak je to neko napravio po nekoj logici, ne znaci da se nacini razmisljanja uvek poklapaju.

 

[alfaunits]

Postoji neka "teorija" (ili bolje receno praksa..) da kada se predje odredjena kolicina memorije, verovatnoca bit flipa (greske u RAMu) postaju zabrinjavajuce za podatke, jer postoji realna mogucnost da ce neki bit flip biti na podacima koji ce se upisati na disk. I neki predlazu da preko 8-16GB se samo ECC memorija koristi, da bi se ta mogucnost desetkovala. (a kao obavezna za file/DB server, cak i omanji)

Slicno vazi i za OC. Verovatnoca da ce pogresna informacija se pasti na RAM poziciji koja ce biti upisana u disk nije zanemarljiva.

Windows ima USN journal i drugi NTFS metadata koji se ponekad upise cak i da ne koristis disk (mada to ne znaci da nista ne pristupa tom disku).

Ovo sto si pitao za bekap, sta ce ti znaciti ako je podatak korumpiran, a ne parity? Nista za taj blok, ali znacice ti da ako ode disk, ili dodje do jos neke greske, sto vise podataka si sacuvao, umesto sinhronizacije, koja sigurno nece nijedan podatak vratiti.
Moguce je da neki RAID kontroler i "razmisli" koja je verovatnoca da je podatak korumpiran a parity dobar, i na osnovu toga uradi restore podataka, a ne parity-a, ali za RAID5 mi uopste ne pada na pamet kako bi ovo proslo, bez nekih metadata tabela koje bi smanjile kapacitet diska.

 

[Condor]

Hvala za pojasnjenje, momci!
Drzacu se backup-a, nadam se jos redovnije, da me ne boli glava zbog ovih gresaka (koje vjerovatno nisu mnogo kriticne, bar u mom slucaju, ali nikad se ne zna).

Inace, za RAM (iako je offtopic), nisam znao da sa povecanjem kapaciteta "pada" pouzdanost (na neki nacin)?! Korisna informacija... Kontam da detaljno testiranje (~24h), recimo sa MemTest86+ moze dosta da preduprijedi ovakve probleme (nevezano da li je masina OC-ovana ili ne).
Btw, svojevremeno sam imao veeeeliki problem sa RAM-om, nekim Kingmax modulom (1 kom.), mislim da sam ga malo kloknuo i racunao sve je ok, dok poslije prilicno vremena nisam skontao da mi se korumpiraju podaci na HDD-u - izludio sam dok nisam skontao da je problem u RAM-u (sve zivo sam prethodno isprovjeravao), iako je savrseno stabilno radio! Od tada sam izvukao pouku i jako detaljno sve testiram kada dodam u konfiguraciju, ili OC-ujem (cak i minimalno).

P.S. ECC moduli, to su oni sa korekcijom greske, ako se dobro sjecam?! Da li su kod takvih modula performanse na nivou ovih non-ECC? Mada mozda nije mjerodavno porediti jer su razlike u cijeni znacajne.

 

[alfaunits]

Ne pada pouzdanost povecanjem kapaciteta u smislu samog RAMa direktno, vec se vise RAMa koristi (bolje je bilo reci u stvari, u slucaju da se KORISTI vise RAMa, jer nije dovoljno samo da ima vise RAMa na sistemu 🙂), pa je samim tim realnije da ce doci do izrazaja poneka greska.
Verovatnoca moze biti "ista", jedan i trilion bitova recimo (ne secam se iskreno ni priblizno koji je odnos, rekao sam neki veliki broj namerno 🙂), medjutim, ukoliko imas recimo 1GB, dok se "proseta" trilion bitova, treba da se predje 1t/8/1GB puta.
Kada imas 32GB, treba 1t/8/32gb - znaci 32x manje vremena. Sasmim tim, ukoliko se i koristi toliko vise memorije, sansa da dodje do greske je 32x veca.

Preko svega toga, veci moduli su gusci ("gustiji"), pa, ako se ne varam, i mogucnost greske im jeste veca dodatno.

ECC moduli su "sporiji" dosta, jer nema overclockerskih ECC memorija 🙂 One rade na toj jednoj frek/timings, na kojoj su dizajnirani i to je to. A to je obicno dosta sporije. Mada u praksi, koliko sam video, memorija je samo za bench bila jako bitna 🙂 Ako poredimo ECC i obicnu memoriju istih frekv./timings, razlika je nekih 2-3%, bukvalno u nivou statisticke greske.
Cena... pa i nije neka razlika uvek. Evo, sad sam bacio pogled, cak ima Kingston DDR3-1866 ECC memorije, 24GB za 240e. Sto je cak i jeftinije od nekih obicnih memorija DDR3 kod nas 😀
Brendirana ECC memorija je skupa, dok Crucial i Kingston koji se kupuju van OEM dranja su sasvim OK cena.


Treba imati na umu da ne podrzava vise svaki CPU ECC memoriju! Zakljucno sa Nehalemom sam i pratio kako je sta, ali sam sada izasao iz te price, ne znam ni koja je aktuelna CPU platforma 🙂

 

[Condor]

Potpuno jasno sad, hvala na finom objasnjenju. 😉

Zakljucno sa Nehalemom sam i pratio kako je sta, ali sam sada izasao iz te price, ne znam ni koja je aktuelna CPU platforma 🙂

Isti sam ti i ja, nekako sam poceo da zaostajem u slicnom momentu, prosto mi nedostaje vremena (iako nisam izgubio zelju da "budem u toku", ali eto). 😀

 

[alfaunits]

Ja sam prestao tada jer od tada su procesori postali dovoljno jako da me bas briga dalje dok rade🙂

 

[Condor]

Ja sam udovoljio svojim zeljama sa vec prastarom Core arhitekturom i ne planiram da se ponovim jos bar godinu-dvije (ako ne budem morao prinudno). 😉