Cred ca ce vrea el sa spuna este ca avind checksumuri (si cred ca si ceva error correction code) pentru fiecare unitate de date, la fiecare citire standard (as in citire din timpul utilizarii NORMALE) ai posibilitatea sa iti dai seama relativ usor daca datele citite sint in regula sau nu (si daca ai si ceva redundanta sa si corectezi situatia). Lucrul asta la raid1 poate fi ceva mai dificil, pentru ca majoritatea implementarilor la citirea unui bloc de date nu fac de fapt citire de pe ambele discuri ca sa si compare daca blocurile citite sint sau nu identice. Nu ca nu s-ar putea, dar nu se face mereu. Scrubul ala de zfs probabil ca forteaza aceasta verificare la nivelul intregului filesystem, dar nu depinzi de el pt detectia erorilor.
De asemenea, este adevarat ca pentru fiecare bloc lowlevel in hard disc exista un alt checksum care este validat de controllerul intern al discului si eventual semnalat/realocat, dupa caz. Dar asta nu te protejeaza decit de erorile care au aparut pe suprafata magnetica ulterior momentului scrierii. Exista destule lucruri ingrijoratoare la zfs, precum cit de usor este ca atunci cind chiar ti s-au corupt discurile peste un anumit nivel cit de usor este sa repari filesystemul cu fsck (si eventual sa ramii si cu ceva date recuperate). Ext3/4 este relativ robust din punctul asta de vedere, ai sanse mari ca de pe un volum plin de erori logice sa restaurezi o cantitate semnificativa de date. Nu stiu cit de usor e lucrul asta pe un setup mai complicat de zfs atunci cind "shit hits the fan". Dar la capitolul utilitate checksumuri pt ce salveaza si validare checksum la fiecare citire de unitati de pe disc versus a nu avea deloc, e clar ca e mai bine sa le ai. Ba mai mult, chiar si aplicatiile de deasupra vin in layerul lor si pentru blocurile lor isi fac alt checksum (bazele de date fiind un exemplu). Discutia versus "nu ne trebuie asigurari suplimentare ca noi punem doar cabluri bune" mi se pare un pic puerila, atita vreme cit validarea unui checksum la citire e o operatie cu cost minim nu poti argumenta ca nu e bine sa ai SI asa ceva, pentru ca tu ai cabluri bune si discuri enterprise. Chiar si alea dau rateuri, doar ca cu probabilitate mai mica. Culmea e ca eu la rindul meu sint zfs sceptic, atit pentru motivul de mai sus referitor la sansele de recovery atunci cind chiar se duce in balarii cit si pentru ca nu-l pot folosi "normal" sau "oficial" pe kerneluri linux (sa stau sa-l builduiesc de mina nu mi se pare convenabil). Dar trebuie a recunosc ca cel putin la capitolul asta cu validarea datelor citite are un avantaj, si mi se pare o prostie sa argumentezi ca un sistem de securitate in plus este prost pentru ca tu tii la datele tale si ai cabluri bune si hardware de top. On Fri, 2013-11-15 at 13:16 +0200, Andrei Pascal wrote: > Of of, măi măi... Poți lăsa scrub-ul ăla să ruleze , e drept - dar tot îți > va fute discurile. Și, întreb eu, CÂND ruleziscrub-ul? Dacă îl rulezi la > scriere și cu asta basta, nu e nici o diferență între ZFS și RAID 5 de > exemplu. Plus că e la mintea cocoșului că într-un mirror nu pui discuri din > același lot de producție. > > Argumentul cu rebuildul mirror-ului ZFS e valabil, dar, cum spuneam mai > înainte, ZFS e și volume manager și filesystem iar suport comercial n-are > decât pe Solaris. Pentru tine acasă însă merge și pe *bsd, nu-i bai. Sau > dacă nu te interesează suportul. > > > 2013/11/15 Iulian Murgulet <[email protected]> > > > > > > > ... mai fac o incercare. > > > > 1. MD RAID1(2xHDD) > > > > Scriu un block de date care sa zicem contine "A1B2"(ca idee) pe un > > /dev/mdX, asta inseamna ca in spate, md-ul va scrie acel block identic > > pe HDD1 si pe HDD2. HDD1 si 2 zice gata e OK, am terminat > > > > > > Citesc acel block de date peste 3 luni(ipotetic), md-ul il va citi > > de pe HDD1 sau de pe HDD2(round-robin), daca il poate citi fara erori, > > zice ca e OK. > > > > - in astea 3 luni sa intamplat ceva(orice vreti voi sa va imaginati), > > si cand citesc el citeste cu SUCCES "A1B0" - e bine? Cu siguranta nu e > > bine. > > > > 2. ZFS-mirror(2xHDD) > > > > Inainte de a scrie, calculez un check-sum pt. "A1B2", si scriu pe HDD1 > > si 2 atat blocul de date cat SI check-sum-ul pe fiecare disk. > > > > Citesc acel block de date peste 3 luni(ipotetic), zfs-ul il va citi > > de pe HDD1 sau de pe HDD2(round-robin), calculez check-sum-ul la ce am > > citit si compar cu > > check-sum-ul stocat pe disk la scriere, daca bate verificarea, este OK. > > Daca nu bate verificarea, atunci citesc din nou acelasi bloc > > oglindit care se afla pe HDD2. Daca aici verificarea este OK, atunci, > > scriu din din nou acelasi bloc si pe HDD1, si returnez datele CORECTE > > pt. acel block aplicatiei. > > > > ZFS scrub, asta face, citeste fiecare bloc de date(si atentie, daca > > am un pool de 2 TB, da eu am date doar pe 10 GB, verific doar cei 10 > > GB de date), si verifica daca bate cu check-sum-ul stocat la scriere. > > > > > > 1. MD RAID1(2xHDD) > > > > - dintr-un motiv oarecare HDD2 a fost scos din raid(nu discutam cauza) > > - il bagam din nou in raid dupa 3 ore sa zicem(acelasi disk ieftin > > ...sau unul nou din clasa enterprise), OK se incepe sincronizarea, de > > la zero, pe 2 TB chit ca eu am doar 500 GB de date; > > > > 2. ZFS-mirror(2xHDD) > > > > - dintr-un motiv oarecare HDD2 a fost scos din raid(nu discutam cauza) > > - il bagam din nou in raid dupa 3 ore sa zicem(acelasi disk ieftin > > ...sau unul nou din clasa enterprise), OK se incepe sincronizarea, dar > > se va face o sincronizare pe doar 500 GB de date si nu pe 2TB. > > > > .... cam asta-i tot. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------- > > This message was sent using IMP, the Internet Messaging Program. > > > > > > ================================ ATENTIONARI ============================= > > > > - pentru atasamente tip Office va rugam sa folositi format OFFICE 97; > > - nu trimiteti date personale (CNP, copii dupa acte de identitate etc). > > > > O lista completa cu reguli de utilizare exista la: > > > > http://gw.casbv.ro/forum_smf/index.php?topic=2000.msg3106#msg3106 > > > > C.A.S.J. Brasov - B-dul Mihail Kogalniceanu, nr. 11,Brasov > > [web-site]: http://www.casbv.ro > > [forum]: http://gw.casbv.ro/forum_smf/index.php > > > > ========================================================================== > > > > _______________________________________________ > > RLUG mailing list > > [email protected] > > http://lists.lug.ro/mailman/listinfo/rlug > > > > > _______________________________________________ RLUG mailing list [email protected] http://lists.lug.ro/mailman/listinfo/rlug
