Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
> > Tu omi?i un lucru. Adminul este un simplu executant. În func?ie de > > situa?ie, poate fi ?i factor de influen??, dar EXTREM de rar e factor de > > decizie. Pe cale de consecin?? adminul e pus în 99% din cazuri s? fac? din > > rahat bici care bici mai trebuie s? ?i pocneasc? (nu la modul în care iese > > fumul magic) iar dac? $CEVA merge prost ÎNTOTDEAUNA va fi vina lui ?i nu a > > factorilor de decizie care nu au alocat resursele necesare (bani ?i timp) > > pentru o solu?ie potrivit? problemei. > > > > Dac? ne lu?m dup? defini?ia ta, eu unul ar trebui s? zic c? nu am v?zut > > niciodat? admini buni în locuri cu management prost. Ceea ce nu e > > adev?rat. > > Ma re-citez: > "Sigur exista si situatii in care nu ai cum sa obtii rezultate intr-un > anumit context" > Sunt sigur ca daca sistemul de pensii va colapsa ( si probabil se va intampla la un moment dat ) nu va fi din cauza raid-ului software :) De asemenea, nici macar ZFS nu ne poate proteja de radiatiile gamma, pulsul electromagnetic sau atacurile cu drone extraterestre. De fapt nu raid-ul e cel care ar trebui sa protejeze integritatea datelor, ci backup-ul. Raid-ul te ajuta ca in cele mai multe cazuri sa nu apelezi la backup, ceea ce de regula e un dezavantaj pentru ca de obicei asta te face sa fii mai putin vigilent in verificarea lui :) Toate chestiile astea SF cu silent corruption si efectul razelor gamma asupra anemonelor pleaca de la premisa ca datele au o semnificatie in sine, ceea ce in general nu e adevarat; fii sigur ca daca ii trimiti din greseala pensia mai mare sau mai mica lui Nea Ion fie nea Ion fie postasul o sa se sesizeze, iar datele se reconstituie din documente. Iar daca e vorba de date reprezentand software, se sesizeaza adminul cand crapa masina :) > ___ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug -- Mihai Bădici http://mihai.badici.ro ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
Quoting Andrei Pascal : > 2013/11/21 Iulian Murgulet > >> >>Si intotdeauna contextul/peisajul este esential. Se pot aplica >> tehnologii >> "proaste/nefiabile/non-enterprise" care intr-un anumit context/peisaj >> sa de rezultatele scontate, dar pot fi si situatii in care se aplica >> tehnologii "bune/fiabile/enterprise" care sa nu conduca la rezultatele >> dorite. Aici se face >> diferenta intre un admin bun/capabil si unul mai putin bun. Adica un >> admin bun, cu o dotare tehnica existenta, cu un anumit buget la >> dispozitie, obtine rezultatele dorite/asteptate (si constante in timp) >> de management! Sigur exista si situatii in care nu ai cum sa obtii >> rezultate intr-un anumit context. >> >> > Tu omi?i un lucru. Adminul este un simplu executant. În func?ie de > situa?ie, poate fi ?i factor de influen??, dar EXTREM de rar e factor de > decizie. Pe cale de consecin?? adminul e pus în 99% din cazuri s? fac? din > rahat bici care bici mai trebuie s? ?i pocneasc? (nu la modul în care iese > fumul magic) iar dac? $CEVA merge prost ÎNTOTDEAUNA va fi vina lui ?i nu a > factorilor de decizie care nu au alocat resursele necesare (bani ?i timp) > pentru o solu?ie potrivit? problemei. > > Dac? ne lu?m dup? defini?ia ta, eu unul ar trebui s? zic c? nu am v?zut > niciodat? admini buni în locuri cu management prost. Ceea ce nu e adev?rat. Ma re-citez: "Sigur exista si situatii in care nu ai cum sa obtii rezultate intr-un anumit context" > > -- > Ave > http://flying.prwave.ro > ___ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug > 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 00.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 RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
2013/11/21 Iulian Murgulet > >Si intotdeauna contextul/peisajul este esential. Se pot aplica > tehnologii > "proaste/nefiabile/non-enterprise" care intr-un anumit context/peisaj > sa de rezultatele scontate, dar pot fi si situatii in care se aplica > tehnologii "bune/fiabile/enterprise" care sa nu conduca la rezultatele > dorite. Aici se face > diferenta intre un admin bun/capabil si unul mai putin bun. Adica un > admin bun, cu o dotare tehnica existenta, cu un anumit buget la > dispozitie, obtine rezultatele dorite/asteptate (si constante in timp) > de management! Sigur exista si situatii in care nu ai cum sa obtii > rezultate intr-un anumit context. > > Tu omiți un lucru. Adminul este un simplu executant. În funcție de situație, poate fi și factor de influență, dar EXTREM de rar e factor de decizie. Pe cale de consecință adminul e pus în 99% din cazuri să facă din rahat bici care bici mai trebuie să și pocnească (nu la modul în care iese fumul magic) iar dacă $CEVA merge prost ÎNTOTDEAUNA va fi vina lui și nu a factorilor de decizie care nu au alocat resursele necesare (bani și timp) pentru o soluție potrivită problemei. Dacă ne luăm după definiția ta, eu unul ar trebui să zic că nu am văzut niciodată admini buni în locuri cu management prost. Ceea ce nu e adevărat. -- Ave http://flying.prwave.ro ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
2013/11/21 Abibula Aygun > Ce vremuri! Daca aveai HDD de 40 GB erai boiet. Erau Quantum Fireballurile > la care periodic le pica firmwareul sau initial pe 486 HDD de 10 GB si 16MB > RAM SIMM. > Pe vremea 486-urilor HDD-urile erau cam cu două ordine de magnitudine mai mici, adică de sute de MB, nu de zeci de GB. De fapt, în mod obișnuit un 486 nici nu pornește de pe un sistem instalat pe un HDD de 10GB, tre' să faci HDD-ul să raporteze BIOS-ului că-i mai mic (unele se pot seta din jumper pentru așa ceva) și să ai managerul de boot pe o partiție pe la începutul discului, detalii la http://web.inter.nl.net/hcc/J.Steunebrink/bioslim.htm Sorry, duty calls! http://xkcd.com/386/ :) ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
Quoting Tiberiu ATUDOREI : > Scuze ca ma bag si eu in discutie mai pe la spartul targului, dar "nu ma > pot abtine". > As avea sugestia sa luati in considerare faptul ca orice asertiune facuta > de Ave legata de topicele software raid / extx / zfs are urmatoarele > argumente aditionale: > -este unul dintre putinii RHCE de pe forum > - lucreaza la o firma care ( pot sa zic fara urma de rusine) are maximum > de experienta pe chestiile enuntate mai sus ( ca sa fiu mai explicit pentru > cine nu ne cunoaste, avem si cate o adresa de mail cu @oracle.com in coada) > -prin natura jobului avem si maximum de expunere pe tehnologiile enterprise > storage ( in fiecare saptamina instalam sisteme cu SUTE de HDD-uri > enterprise, cu Linux si cu Solaris) > -din tot ce instalam noi, ZFS e folosit exclusiv pe Solaris (sa nu intram > in polemici legate de model de licentiere , zfs in kernel,samd,samd ... ) > - marea majoritate a sistemelor (95%+) sunt cu Linux .. Si cu chestiile > considerate "unreliable" mai sus in topic (mii de clienti aubagat miliarde > de dolari in sisteme mission-critical bazate pe tehnologii 'unreliable'... > si noi mai suntem inca pe piata...f.ciudat) > -de notat ca pentru chestiile de back-up sau care necesita alta categorie > de features (ZFS storage appliance) si pe sistemele cu Solaris se foloseste > totusi ZFS > -si dintre zecile de instalari (ale lui Andrei, sute in cazul meu) cu > mii/zeci de mii de discuri (nu exagerez deloc, un full rack de servere are > fix 200 de discuri) cred ca stim amandoi doar vreo 2-3 cazuri de servere > date cu rotile in sus din motive de storage (si in toate cazurile discurile > erau bine mersi, buba era in alta parte) > - ca sa iti faci o idee de diferenta de clasa de hardware intre discurile > de tip consumer si cele enterprise..cele enterprise au capacitatea cu un > ordin de marime mai mic, pretul cuun ordin de marime mai mare, ca si > indicatorii de fiabilitate zunt cu un ordin de marime mai mare (plus ca au > o gramada de tehnologii in plus gen amortizare vibratii, control de > temperatura, controlul vitezei de rotatie samd samd). Au si discurile > consumer tehnologii specifice dar in mare sunt cam opusul celor > entrerprise: control putere consumata, control acustica, parcare automataa > capetelor samd,samd. Ia baga tu niste discuri cu tehnologie green in > maretul storage zfs facut cu freenas si vezi peste cateva luni ce se > intampla (nu zic ca nu se poate folosi, trebuie sa iei anumite precautii si > sa faci un pic de tuning la discurile alea ... sistemul meu storage de > acasa e de 18 TB facuti exact cu ZFS si nas4free ... asta e un fork de > freenas dar care e bazat pe freebsd 9 si nu pe versiunea 8 ca freenas). Mai > arunca o privire din cand in cand pe valorile raportate de smartd ...dar > TOATE valorile. Si vezi si dinamica lor in timp. > Dar vad ca m-am intins prea mult. Cam asta era sugestia de baza: cand apar > observatii legate de storage facute de wolfy, mituc, ave sau altii mai > vechi de pe forum...eu zic sa luati notite daca nu va simtiti guru in > domeniu. Nu de alta dar noi lucram cu discuri cam de cand capacitatile se > calculau in zeci de megabytes si cu storage pe linux cam de vreo 15 ani > (cazul meu). > Si concluzia mea personala e : la storage nu poti sa faci din rahat bici ca > "pocneste" (dar numai o data). Depinde de peisaj, adica daca iti tii "toate ouale intr-un singur cos" sau nu. Daca ai mai multe noduri/cosuri(N>2), prinse intr-un cluster, nu e nici o catastrofa daca face "poc" unul sau mai multe noduri, atata timp cat ai macar un nod supravetuitor! Si daca pe fiecare nod ai alt FS(ZFS/ext4/XFS/etc), si alt tip de raid(mdraid/hardware/ZFS mirror), SO din distributii diferite cred ca poti sa stai linistit si cu dotari non-enterprise! Garantat nu vor pocni toate odata! Si intotdeauna contextul/peisajul este esential. Se pot aplica tehnologii "proaste/nefiabile/non-enterprise" care intr-un anumit context/peisaj sa de rezultatele scontate, dar pot fi si situatii in care se aplica tehnologii "bune/fiabile/enterprise" care sa nu conduca la rezultatele dorite. Aici se face diferenta intre un admin bun/capabil si unul mai putin bun. Adica un admin bun, cu o dotare tehnica existenta, cu un anumit buget la dispozitie, obtine rezultatele dorite/asteptate (si constante in timp) de management! Sigur exista si situatii in care nu ai cum sa obtii rezultate intr-un anumit context. > On Nov 15, 2013 1:41 PM, "Andrei Pascal" wrote: > >> 2013/11/15 Iulian Murgulet >> >> > Quoting Andrei Pascal : >> > >> > > 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? >> > >> > ... on-demand >> > >> >> C?t de des? Cum te asiguri c? l-ai rulat FIX înainte s? apar? orice >> posibil? corup?ie? Dac? datele s-au corupt înainte s? rulezi scrub-ul? >> >> >> > > Dac? îl rulezi la >> > > scriere ?i cu asta basta, nu e nici o diferen?? î
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
Ce vremuri! Daca aveai HDD de 40 GB erai boiet. Erau Quantum Fireballurile la care periodic le pica firmwareul sau initial pe 486 HDD de 10 GB si 16MB RAM SIMM. Asta ca sa nu mai pun microcalculatoarele Cobra ( primul sistem de calcul asamblat de mine) , HC-urile, Cip-urile si altele. Am un amic ce a reconstruit de la zero un Felix cu unitate de banda cu tot. Il gasiti pe individ pe elforum.ro. Pe cand lucra la bulgari, isi cumparase de la obor trei statii de emisie receptie duplex dr la tanc-uri dezmembrate si transmitea net pina in Bulgaria. Pe ce comunica? Pai pe niste terminale DAF2000, text only. Old school style! În data de 20.11.2013 23:01, "Tiberiu ATUDOREI" a scris: > Scuze ca ma bag si eu in discutie mai pe la spartul targului, dar "nu ma > pot abtine". > As avea sugestia sa luati in considerare faptul ca orice asertiune facuta > de Ave legata de topicele software raid / extx / zfs are urmatoarele > argumente aditionale: > -este unul dintre putinii RHCE de pe forum > - lucreaza la o firma care ( pot sa zic fara urma de rusine) are maximum > de experienta pe chestiile enuntate mai sus ( ca sa fiu mai explicit pentru > cine nu ne cunoaste, avem si cate o adresa de mail cu @oracle.com in > coada) > -prin natura jobului avem si maximum de expunere pe tehnologiile enterprise > storage ( in fiecare saptamina instalam sisteme cu SUTE de HDD-uri > enterprise, cu Linux si cu Solaris) > -din tot ce instalam noi, ZFS e folosit exclusiv pe Solaris (sa nu intram > in polemici legate de model de licentiere , zfs in kernel,samd,samd ... ) > - marea majoritate a sistemelor (95%+) sunt cu Linux .. Si cu chestiile > considerate "unreliable" mai sus in topic (mii de clienti aubagat miliarde > de dolari in sisteme mission-critical bazate pe tehnologii 'unreliable'... > si noi mai suntem inca pe piata...f.ciudat) > -de notat ca pentru chestiile de back-up sau care necesita alta categorie > de features (ZFS storage appliance) si pe sistemele cu Solaris se foloseste > totusi ZFS > -si dintre zecile de instalari (ale lui Andrei, sute in cazul meu) cu > mii/zeci de mii de discuri (nu exagerez deloc, un full rack de servere are > fix 200 de discuri) cred ca stim amandoi doar vreo 2-3 cazuri de servere > date cu rotile in sus din motive de storage (si in toate cazurile discurile > erau bine mersi, buba era in alta parte) > - ca sa iti faci o idee de diferenta de clasa de hardware intre discurile > de tip consumer si cele enterprise..cele enterprise au capacitatea cu un > ordin de marime mai mic, pretul cuun ordin de marime mai mare, ca si > indicatorii de fiabilitate zunt cu un ordin de marime mai mare (plus ca au > o gramada de tehnologii in plus gen amortizare vibratii, control de > temperatura, controlul vitezei de rotatie samd samd). Au si discurile > consumer tehnologii specifice dar in mare sunt cam opusul celor > entrerprise: control putere consumata, control acustica, parcare automataa > capetelor samd,samd. Ia baga tu niste discuri cu tehnologie green in > maretul storage zfs facut cu freenas si vezi peste cateva luni ce se > intampla (nu zic ca nu se poate folosi, trebuie sa iei anumite precautii si > sa faci un pic de tuning la discurile alea ... sistemul meu storage de > acasa e de 18 TB facuti exact cu ZFS si nas4free ... asta e un fork de > freenas dar care e bazat pe freebsd 9 si nu pe versiunea 8 ca freenas). Mai > arunca o privire din cand in cand pe valorile raportate de smartd ...dar > TOATE valorile. Si vezi si dinamica lor in timp. > Dar vad ca m-am intins prea mult. Cam asta era sugestia de baza: cand apar > observatii legate de storage facute de wolfy, mituc, ave sau altii mai > vechi de pe forum...eu zic sa luati notite daca nu va simtiti guru in > domeniu. Nu de alta dar noi lucram cu discuri cam de cand capacitatile se > calculau in zeci de megabytes si cu storage pe linux cam de vreo 15 ani > (cazul meu). > Si concluzia mea personala e : la storage nu poti sa faci din rahat bici ca > "pocneste" (dar numai o data). > On Nov 15, 2013 1:41 PM, "Andrei Pascal" wrote: > > > 2013/11/15 Iulian Murgulet > > > > > Quoting Andrei Pascal : > > > > > > > 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? > > > > > > ... on-demand > > > > > > > Căt de des? Cum te asiguri că l-ai rulat FIX înainte să apară orice > > posibilă corupție? Dacă datele s-au corupt înainte să rulezi scrub-ul? > > > > > > > > Dac? îl rulezi la > > > > scriere ?i cu asta basta, nu e nici o diferen?? între ZFS ?i RAID 5 > de > > > > exemplu. > > > > > >Ba da este. ZFS nu are "RAID-5 write hole"! > > > > > > Ok, fie cum zici tu. > > > > > > > > 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 > > > > > > ... iar restul e poveste ? > > > > > > > Vezi mai sus... > > > > > > > > înainte, ZFS e
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
Scuze ca ma bag si eu in discutie mai pe la spartul targului, dar "nu ma pot abtine". As avea sugestia sa luati in considerare faptul ca orice asertiune facuta de Ave legata de topicele software raid / extx / zfs are urmatoarele argumente aditionale: -este unul dintre putinii RHCE de pe forum - lucreaza la o firma care ( pot sa zic fara urma de rusine) are maximum de experienta pe chestiile enuntate mai sus ( ca sa fiu mai explicit pentru cine nu ne cunoaste, avem si cate o adresa de mail cu @oracle.com in coada) -prin natura jobului avem si maximum de expunere pe tehnologiile enterprise storage ( in fiecare saptamina instalam sisteme cu SUTE de HDD-uri enterprise, cu Linux si cu Solaris) -din tot ce instalam noi, ZFS e folosit exclusiv pe Solaris (sa nu intram in polemici legate de model de licentiere , zfs in kernel,samd,samd ... ) - marea majoritate a sistemelor (95%+) sunt cu Linux .. Si cu chestiile considerate "unreliable" mai sus in topic (mii de clienti aubagat miliarde de dolari in sisteme mission-critical bazate pe tehnologii 'unreliable'... si noi mai suntem inca pe piata...f.ciudat) -de notat ca pentru chestiile de back-up sau care necesita alta categorie de features (ZFS storage appliance) si pe sistemele cu Solaris se foloseste totusi ZFS -si dintre zecile de instalari (ale lui Andrei, sute in cazul meu) cu mii/zeci de mii de discuri (nu exagerez deloc, un full rack de servere are fix 200 de discuri) cred ca stim amandoi doar vreo 2-3 cazuri de servere date cu rotile in sus din motive de storage (si in toate cazurile discurile erau bine mersi, buba era in alta parte) - ca sa iti faci o idee de diferenta de clasa de hardware intre discurile de tip consumer si cele enterprise..cele enterprise au capacitatea cu un ordin de marime mai mic, pretul cuun ordin de marime mai mare, ca si indicatorii de fiabilitate zunt cu un ordin de marime mai mare (plus ca au o gramada de tehnologii in plus gen amortizare vibratii, control de temperatura, controlul vitezei de rotatie samd samd). Au si discurile consumer tehnologii specifice dar in mare sunt cam opusul celor entrerprise: control putere consumata, control acustica, parcare automataa capetelor samd,samd. Ia baga tu niste discuri cu tehnologie green in maretul storage zfs facut cu freenas si vezi peste cateva luni ce se intampla (nu zic ca nu se poate folosi, trebuie sa iei anumite precautii si sa faci un pic de tuning la discurile alea ... sistemul meu storage de acasa e de 18 TB facuti exact cu ZFS si nas4free ... asta e un fork de freenas dar care e bazat pe freebsd 9 si nu pe versiunea 8 ca freenas). Mai arunca o privire din cand in cand pe valorile raportate de smartd ...dar TOATE valorile. Si vezi si dinamica lor in timp. Dar vad ca m-am intins prea mult. Cam asta era sugestia de baza: cand apar observatii legate de storage facute de wolfy, mituc, ave sau altii mai vechi de pe forum...eu zic sa luati notite daca nu va simtiti guru in domeniu. Nu de alta dar noi lucram cu discuri cam de cand capacitatile se calculau in zeci de megabytes si cu storage pe linux cam de vreo 15 ani (cazul meu). Si concluzia mea personala e : la storage nu poti sa faci din rahat bici ca "pocneste" (dar numai o data). On Nov 15, 2013 1:41 PM, "Andrei Pascal" wrote: > 2013/11/15 Iulian Murgulet > > > Quoting Andrei Pascal : > > > > > 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? > > > > ... on-demand > > > > Căt de des? Cum te asiguri că l-ai rulat FIX înainte să apară orice > posibilă corupție? Dacă datele s-au corupt înainte să rulezi scrub-ul? > > > > > Dac? îl rulezi la > > > scriere ?i cu asta basta, nu e nici o diferen?? între ZFS ?i RAID 5 de > > > exemplu. > > > >Ba da este. ZFS nu are "RAID-5 write hole"! > > > > Ok, fie cum zici tu. > > > > > 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 > > > > ... iar restul e poveste ? > > > > Vezi mai sus... > > > > > î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. > > > > > > > ... nu ma intereseaza. Merge in productie si la mine si la alte case mai > > mari. > > > Mă bucur doar că nu stau în Brașov, pe partea relației mele cu statul > mult-iubit. Și sper că datele despre mine nu sunt ținute pe acele mașini, > că n-o să am nici o plăcere în a alerga pentru a le reface când acel ZFS o > va lua prin copaci. > ___ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug > ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
nu sunt nazist. imi pare rau sa te dezamagesc. t. 2013/11/17 Vali Dragnuta > Mam ce nazist esti... BINEINTELES ca am vrut sa scriu iti detecteaza > maxim un bit eronat, da' m-a luat graba la vale si am scris gresit. Cred > ca toata lumea a inteles ce vroiam sa spun :P > > > > > > > On Sun, 2013-11-17 at 06:54 +0200, tiberiu socaciu wrote: > > "--- Mai exact, de obicei ai paritate, ceea ce inseamna ca-ti corecteaza > > maxim un bit corect." > > > > hmm. puneti mana pe teorie si (re)cititi capitolul "coduri detectoare si > > corectoare de erori". bitul de paritate poate DETECTA doar 1 bit eronat. > > > > t. > > > > > > 2013/11/16 Vali Dragnuta > > > > > On Fri, 2013-11-15 at 17:25 +, Dan Borlovan wrote: > > > > Io nu sint in clar cu o chestie > > > > > > > > hdd-ul are ECC (si da il foloseste). Nu stiu daca memoria cache de pe > > > hdd e si ea macar cu bit de paritate, dar de pe platane erorile de > citire > > > sint detectate (si in masura posibilitatilor corectate) > > > > > > --- Prespunind ca ajunge corect acolo.Oricum, nu stim cit de bun este > > > acel ECC (16bit, 32 bit...ce algoritm...) > > > > > > > > sata are si el ceva crc, ca si sirmele de firma pot avea probleme > (asta > > > ca sa nu ma leg de ingeniosul care a proiectat mufele, care ies afara > numai > > > cind te uiti la ele) > > > --- Da > > > > > > > > memoria dintr-un server e ecc > > > --- Mai exact, de obicei ai paritate, ceea ce inseamna ca-ti > corecteaza > > > maxim un bit corect. Tocmai am o masina care logeaza erori de paritate > > > pe un anume bank de memorie si totusi crapa frecvent. Presupun ca > > > dimm-ul e atit de stricat incit > > > inregistreaza deseori coruptii dincolo de bitul corectat de paritate. > > > Shit can happen, easily. BTW, de ce crezi ca sint masini care nu numai > > > ca folosesc memorii ECC, dar au posibilitatea sa implementeze si > > > mirroring de memorie ? Pentru ca uneori e nevoie de mai mult. > > > > http://h18000.www1.hp.com/products/servers/technology/memoryprotection.html > > > > > > > > > > > > > > nu stiu memoria cache din controller-ul raid, cel putin unele > folosesc > > > memorii simple de pc, dar la cele profi ma astept sa aiba si ele ecc > > > > > > > > pe ethernet avem si acolo checksum-uri > > > > > > --- Sigur. Dar sint sigur ca stii ca avem ecc in frame-ul ethernet dar > > > avem si checksum (doar pt header,ce-i drept) in header-ul IP si mai > avem > > > si in TCP...Pentru ca e clar ca nu doar procesul de transmitere poate > > > provoca erorile ci si eventual procesul de transmisie poate genera > erori > > > ci si softwareul prin care trece intre transmisii :) > > > > > > > > > > > > > > Si atunci, exceptind cazuri extreme > > > > - de coruptie intre doua medii de transfer (gen bug in fw la > > > controllerul raid sau hdd care nu onoreaza un flush de cache) > > > > - modificari care trec de suma de control (ca nah orice algoritm de > > > suma de control mai scurta decit datele respective va avea coliziuni -> > > > cazuri de erori nedetectate) > > > > > > > > de unde naiba atitea silent data corruption? > > > > > > --- Sigur, nu zice nimeni ca sint asa frecvente - probabil ca cu cit ai > > > hardware mai scump cu atit mai putine erori ai. Da' guess what, de > multe > > > ori hardwareul mai scump isi are rezilienta fix in mecanisme de > detectie > > > si corectie a erorilor suplimentare (vezi memory mirroring de mai sus). > > > Am avut masini care erau rebootate normal (deci nu datorita unui > crash!) > > > dupa ~180 zile de uptime si fsck.ext3 full gasea mereu si corecta > > > diverse erori minore, in ciuda faptului ca masina nu a avut intreruperi > > > bruste, nu avea probleme cu memoriile etc. > > > De unde ? Probabil ca si de la software bugs si alti factori, daca mai > > > cauti online vei mai gasi diverse referinte. > > > Cert e ca cu cit volumele de date pe care le avem sint mai mari, cu > atit > > > probabilitatea de a intilni aceste erori este mai mare. > > > > > > > > > > > > ___ > > > RLUG mailing list > > > RLUG@lists.lug.ro > > > http://lists.lug.ro/mailman/listinfo/rlug > > > > > ___ > > RLUG mailing list > > RLUG@lists.lug.ro > > http://lists.lug.ro/mailman/listinfo/rlug > > > ___ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug > ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
Mam ce nazist esti... BINEINTELES ca am vrut sa scriu iti detecteaza maxim un bit eronat, da' m-a luat graba la vale si am scris gresit. Cred ca toata lumea a inteles ce vroiam sa spun :P On Sun, 2013-11-17 at 06:54 +0200, tiberiu socaciu wrote: > "--- Mai exact, de obicei ai paritate, ceea ce inseamna ca-ti corecteaza > maxim un bit corect." > > hmm. puneti mana pe teorie si (re)cititi capitolul "coduri detectoare si > corectoare de erori". bitul de paritate poate DETECTA doar 1 bit eronat. > > t. > > > 2013/11/16 Vali Dragnuta > > > On Fri, 2013-11-15 at 17:25 +, Dan Borlovan wrote: > > > Io nu sint in clar cu o chestie > > > > > > hdd-ul are ECC (si da il foloseste). Nu stiu daca memoria cache de pe > > hdd e si ea macar cu bit de paritate, dar de pe platane erorile de citire > > sint detectate (si in masura posibilitatilor corectate) > > > > --- Prespunind ca ajunge corect acolo.Oricum, nu stim cit de bun este > > acel ECC (16bit, 32 bit...ce algoritm...) > > > > > > sata are si el ceva crc, ca si sirmele de firma pot avea probleme (asta > > ca sa nu ma leg de ingeniosul care a proiectat mufele, care ies afara numai > > cind te uiti la ele) > > --- Da > > > > > > memoria dintr-un server e ecc > > --- Mai exact, de obicei ai paritate, ceea ce inseamna ca-ti corecteaza > > maxim un bit corect. Tocmai am o masina care logeaza erori de paritate > > pe un anume bank de memorie si totusi crapa frecvent. Presupun ca > > dimm-ul e atit de stricat incit > > inregistreaza deseori coruptii dincolo de bitul corectat de paritate. > > Shit can happen, easily. BTW, de ce crezi ca sint masini care nu numai > > ca folosesc memorii ECC, dar au posibilitatea sa implementeze si > > mirroring de memorie ? Pentru ca uneori e nevoie de mai mult. > > http://h18000.www1.hp.com/products/servers/technology/memoryprotection.html > > > > > > > > > > nu stiu memoria cache din controller-ul raid, cel putin unele folosesc > > memorii simple de pc, dar la cele profi ma astept sa aiba si ele ecc > > > > > > pe ethernet avem si acolo checksum-uri > > > > --- Sigur. Dar sint sigur ca stii ca avem ecc in frame-ul ethernet dar > > avem si checksum (doar pt header,ce-i drept) in header-ul IP si mai avem > > si in TCP...Pentru ca e clar ca nu doar procesul de transmitere poate > > provoca erorile ci si eventual procesul de transmisie poate genera erori > > ci si softwareul prin care trece intre transmisii :) > > > > > > > > > > Si atunci, exceptind cazuri extreme > > > - de coruptie intre doua medii de transfer (gen bug in fw la > > controllerul raid sau hdd care nu onoreaza un flush de cache) > > > - modificari care trec de suma de control (ca nah orice algoritm de > > suma de control mai scurta decit datele respective va avea coliziuni -> > > cazuri de erori nedetectate) > > > > > > de unde naiba atitea silent data corruption? > > > > --- Sigur, nu zice nimeni ca sint asa frecvente - probabil ca cu cit ai > > hardware mai scump cu atit mai putine erori ai. Da' guess what, de multe > > ori hardwareul mai scump isi are rezilienta fix in mecanisme de detectie > > si corectie a erorilor suplimentare (vezi memory mirroring de mai sus). > > Am avut masini care erau rebootate normal (deci nu datorita unui crash!) > > dupa ~180 zile de uptime si fsck.ext3 full gasea mereu si corecta > > diverse erori minore, in ciuda faptului ca masina nu a avut intreruperi > > bruste, nu avea probleme cu memoriile etc. > > De unde ? Probabil ca si de la software bugs si alti factori, daca mai > > cauti online vei mai gasi diverse referinte. > > Cert e ca cu cit volumele de date pe care le avem sint mai mari, cu atit > > probabilitatea de a intilni aceste erori este mai mare. > > > > > > > > ___ > > RLUG mailing list > > RLUG@lists.lug.ro > > http://lists.lug.ro/mailman/listinfo/rlug > > > ___ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
"Sigur, dar bun = ce rata de corupere accepta inainte de a fi pacalit (vezi paritatea care poate detecta doar un bit corupt, dupa care intri in zonele in care poti avea date corupte cu paritate corecta)." dupa ce am citit thread-ul asta, m-am ingrozit ca acceptati cu nonsalanta conceptul de BER la accesarea datelor de pe suporturile externe :( t. 2013/11/16 Vali Dragnuta > On Sat, 2013-11-16 at 12:23 +, Dan Borlovan wrote: > > > --- Prespunind ca ajunge corect acolo.Oricum, nu stim cit de bun este > > > acel ECC (16bit, 32 bit...ce algoritm…) > > > > La mediile magnetice sau optice iti trebe un ecc destul de serios. Mai > ales la densitatea de informatie de acuma (c'mon, 6TB intr-un singur hdd cu > 7 platane… in alte epoci hdd-ul avea 10MB) > > > > Nu stiu la hdd; la cdrom in mod date ai vreo 276 de octeti (nu biti) de > ECC pentru fiecare 2048 de octeti de date, nu doar 32 de biti de detectie > La cdrom da,(cred ca e in standard, si e normal sa fie public si > standard astfel ca toate unitatile sa poata citi toate discurile); > la hdd-uri din cite stiu numarul de biti redundanti si nici nu cred ca > sint informatii care trebuie facute publice : platanele nu sint > schimbate, asa ca fiecare producator este liber sa-si rezerve cit > considera de cuviinta pentru acel disc in functie de pretul cerut pe > disc, garantia oferita si nivelul de activitate pe care il anticipeaza > pentru acel model. > > > > > > > Ideea de aici e nu cit de "bun" e - in sensul cite erori poate corecta - > ci faptul ca exista un mecanism de _detectie_ a erorilor > > Sigur, dar bun = ce rata de corupere accepta inainte de a fi pacalit > (vezi paritatea care poate detecta doar un bit corupt, dupa care intri > in zonele in care poti avea date corupte cu paritate corecta). > > > > > Pe noi ne deranjeaza silent corruption - erorile nedetectate - nu > erorile detectate > Nu inteleg ce vrei sa spui aici. Erorile detectate prin faptul ca iti > crapa o masina sau ai erori in filesystem si trebuie sa intervina fsck > sa stearga inozi sau sa mute lanturi in lost+found la mine nu se > califica pt "detectie cu succes". Nemaipunind la socoteala ca doar fsck > le poate detecta si fsck prin natura sa ruleaza rar. > > > > > > Da in 18 ani in zona IT am vazut > > - un hdd de desktop care corupea silent datele la scriere, banuiesc ca > memoria de pe el era defecta si nu avea mecanism de detectie a erorilor > > - doua laptop-uri care corupeau datele de pe hdd, unul dupa ce bause > cafea/cola, celalalt posibil din cauza ca a stat prea mult pe patura la > caldurica > > > > Nimic voodoo / cabluri posedate / radiatii cosmice, doar defecte care > duc la coruptie de date in etape in care nu exista paritate/crc/ecc > > Well,esti fericit atunci :P Eu am vazut ceva mai multe. > > > > ___ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug > ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
"Nu stiu la hdd; la cdrom in mod date ai vreo 276 de octeti (nu biti) de ECC pentru fiecare 2048 de octeti de date, nu doar 32 de biti de detectie" pentru ca la cdroame, inca de la aparatia lor s-a pus problema CORECTIEI de erori, nu doar a DETECTIEI. (re)vezi lectiile despre "coduri detectoare si coduri corectoare de erori". t. 2013/11/16 Dan Borlovan > > --- Prespunind ca ajunge corect acolo.Oricum, nu stim cit de bun este > > acel ECC (16bit, 32 bit...ce algoritm…) > > La mediile magnetice sau optice iti trebe un ecc destul de serios. Mai > ales la densitatea de informatie de acuma (c'mon, 6TB intr-un singur hdd cu > 7 platane… in alte epoci hdd-ul avea 10MB) > > Nu stiu la hdd; la cdrom in mod date ai vreo 276 de octeti (nu biti) de > ECC pentru fiecare 2048 de octeti de date, nu doar 32 de biti de detectie > > Ideea de aici e nu cit de "bun" e - in sensul cite erori poate corecta - > ci faptul ca exista un mecanism de _detectie_ a erorilor > > Pe noi ne deranjeaza silent corruption - erorile nedetectate - nu erorile > detectate > > Da in 18 ani in zona IT am vazut > - un hdd de desktop care corupea silent datele la scriere, banuiesc ca > memoria de pe el era defecta si nu avea mecanism de detectie a erorilor > - doua laptop-uri care corupeau datele de pe hdd, unul dupa ce bause > cafea/cola, celalalt posibil din cauza ca a stat prea mult pe patura la > caldurica > > Nimic voodoo / cabluri posedate / radiatii cosmice, doar defecte care duc > la coruptie de date in etape in care nu exista paritate/crc/ecc > > Dan > > ___ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug > ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
"--- Mai exact, de obicei ai paritate, ceea ce inseamna ca-ti corecteaza maxim un bit corect." hmm. puneti mana pe teorie si (re)cititi capitolul "coduri detectoare si corectoare de erori". bitul de paritate poate DETECTA doar 1 bit eronat. t. 2013/11/16 Vali Dragnuta > On Fri, 2013-11-15 at 17:25 +, Dan Borlovan wrote: > > Io nu sint in clar cu o chestie > > > > hdd-ul are ECC (si da il foloseste). Nu stiu daca memoria cache de pe > hdd e si ea macar cu bit de paritate, dar de pe platane erorile de citire > sint detectate (si in masura posibilitatilor corectate) > > --- Prespunind ca ajunge corect acolo.Oricum, nu stim cit de bun este > acel ECC (16bit, 32 bit...ce algoritm...) > > > > sata are si el ceva crc, ca si sirmele de firma pot avea probleme (asta > ca sa nu ma leg de ingeniosul care a proiectat mufele, care ies afara numai > cind te uiti la ele) > --- Da > > > > memoria dintr-un server e ecc > --- Mai exact, de obicei ai paritate, ceea ce inseamna ca-ti corecteaza > maxim un bit corect. Tocmai am o masina care logeaza erori de paritate > pe un anume bank de memorie si totusi crapa frecvent. Presupun ca > dimm-ul e atit de stricat incit > inregistreaza deseori coruptii dincolo de bitul corectat de paritate. > Shit can happen, easily. BTW, de ce crezi ca sint masini care nu numai > ca folosesc memorii ECC, dar au posibilitatea sa implementeze si > mirroring de memorie ? Pentru ca uneori e nevoie de mai mult. > http://h18000.www1.hp.com/products/servers/technology/memoryprotection.html > > > > > > nu stiu memoria cache din controller-ul raid, cel putin unele folosesc > memorii simple de pc, dar la cele profi ma astept sa aiba si ele ecc > > > > pe ethernet avem si acolo checksum-uri > > --- Sigur. Dar sint sigur ca stii ca avem ecc in frame-ul ethernet dar > avem si checksum (doar pt header,ce-i drept) in header-ul IP si mai avem > si in TCP...Pentru ca e clar ca nu doar procesul de transmitere poate > provoca erorile ci si eventual procesul de transmisie poate genera erori > ci si softwareul prin care trece intre transmisii :) > > > > > > Si atunci, exceptind cazuri extreme > > - de coruptie intre doua medii de transfer (gen bug in fw la > controllerul raid sau hdd care nu onoreaza un flush de cache) > > - modificari care trec de suma de control (ca nah orice algoritm de > suma de control mai scurta decit datele respective va avea coliziuni -> > cazuri de erori nedetectate) > > > > de unde naiba atitea silent data corruption? > > --- Sigur, nu zice nimeni ca sint asa frecvente - probabil ca cu cit ai > hardware mai scump cu atit mai putine erori ai. Da' guess what, de multe > ori hardwareul mai scump isi are rezilienta fix in mecanisme de detectie > si corectie a erorilor suplimentare (vezi memory mirroring de mai sus). > Am avut masini care erau rebootate normal (deci nu datorita unui crash!) > dupa ~180 zile de uptime si fsck.ext3 full gasea mereu si corecta > diverse erori minore, in ciuda faptului ca masina nu a avut intreruperi > bruste, nu avea probleme cu memoriile etc. > De unde ? Probabil ca si de la software bugs si alti factori, daca mai > cauti online vei mai gasi diverse referinte. > Cert e ca cu cit volumele de date pe care le avem sint mai mari, cu atit > probabilitatea de a intilni aceste erori este mai mare. > > > > ___ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug > ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
On Saturday 16 November 2013 22:29:11 Paul Lacatus wrote: > On 16.11.2013 19:41, Mihai Badici wrote: > > On Saturday 16 November 2013 19:17:50 Vali Dragnuta wrote: > >> Trebuie sa refaci mdadm.conf ( cu ceva gen mdadm --examine --scan > >> > newmdadm.conf ) > > > > Daca dai mdadm -- stop /dev/md127 > > si mdadm --start md0 > > > > Merge? > > Nu merge. Nu exista mdadm --start mdadm -A /dev/md0, m-a luat scrisul pe dinainte. > ___ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug -- Mihai Bădici http://mihai.badici.ro ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
On 16.11.2013 19:41, Mihai Badici wrote: > On Saturday 16 November 2013 19:17:50 Vali Dragnuta wrote: >> Trebuie sa refaci mdadm.conf ( cu ceva gen mdadm --examine --scan >> newmdadm.conf ) > Daca dai mdadm -- stop /dev/md127 > si mdadm --start md0 > > Merge? > Nu merge. Nu exista mdadm --start ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
On Saturday 16 November 2013 19:02:06 Dan Borlovan wrote: > > In principiu daca matricea e asamblata de kernel, nu citeste > > /etc/mdadm/mdadm.conf. > > > > In varianta cu initrd inseamna ca tu nu ai compilat in kernel raid-ul, ci > > il folosesti ca modul. Presupun ca initrd nu asambleaza decat partitia de > > boot ( daca este raid). In cazul asta restul de partitii va fi asamblat > > in scriptul de initializare de mdadm si deci o sa il vada corect, md0 > > Again, on ubuntu (si unul destul de vechi, eu inca sint pe 10.04 - dar deja > avem apa calda de ceva vreme) > > initrd contine niste "magie" (scripturi) care asambleaza doar aria de boot > sau toate ariile, functie de cum e configurat (dpkg --reconfigure mdadm) > > De fapt, cam multe drivere (inclusiv cele de fs) sint compilate ca module, > si nu static in kernel, d-aia avem nevoie de initrd, le ia de acolo si > incarca doar cele de care e nevoie. Nu ca in ziua de azi ar fi mare gaura > de memorie sa bagi totul static in kernel, da' nu-i frumos. > > In initrd exista o copie a mdadm.conf, care in mod evident nu se > actualizeaza singura, ci doar cind refaci initrd-ul (cu update-initramfs > -u) > > So, nu e nevoie de nici un feli de hackereli de gen demontat si remontat > aria in rc.local > A zis cineva de rc.local? Eu am zis ca nu stiu exact daca, atunci cand rulezi mdadm --examine --scan>>newmdadm.conf ( ma rog, eu as fi dat direct mdadm.conf aici) o detecteaza, ea fiind deja asamblata ca 127, ca md127 sau md0. Desi presupun ca o va detecta ca md0, dar pentru siguranta, ziceam sa dea stop la 127 si start la md0. Poate nu am fost eu clar. Asta cu pus in rc.local, toti il folosim dar nu chiar pentru asa ceva :) > Ma astept ca orice distributie care a descoperit apa calda sa aiba > facilitati similare > > Dar na, chestie de gusturi, atita timp cit exista rc.local si vrei sa te > injure urmatorul sysadmin, poti sa faci ce vrei prin el. Recunosc ca si eu > il mai folosesc din cind in cind. > > Dan > ___ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug -- Mihai Bădici http://mihai.badici.ro ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
On Saturday 16 November 2013 19:06:23 Dan Borlovan wrote: > PS: tot in distributiile cu apa calda, montam fs-urile dupa UUID (prietenii > stiu de ce) si nu dupa device, asa ca ni se cam rupe daca e md0, md127 sau Asta e valabil si la distributiile cu bere rece :) Doar ca la el e adaugata manual, dar e o sugestie valida, sa monteze dupa uuid. Singura diferenta e ca la distribuitia mea fara apa calda suportul de md e compilat in kernel, deci nu am nevoie de initrd, sunt ceva ani de cand n-am mai folosit initrd la boot. Daca totusi as avea nevoie, ar trebui sa il fac manual. Fix din cauza asta m-am lovit de aceste probleme, asa ca acum stiu; eu daca vreau sa bootez de pe raid soft, il fac cu --metadata=0.9 sau cam asa ceva, nu-mi amintesc exact optiunea chiar acum. Daca tot stiam am zis sa explic exact cum functioneaza, pentru cei care au deja apa calda si nu au fost nevoiti sa afle singuri cum se incalzeste :) Mihai Bădici http://mihai.badici.ro ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
On 16.11.2013 21:09, manuel "lonely wolf" wolfshant wrote: > On 11/16/2013 08:07 PM, Mihai Badici wrote: >> On Saturday 16 November 2013 19:49:16 Vali Dragnuta wrote: >>> Cam prin toate distributiile cu apa calda s-a convenit de ceva vreme ca >>> arrayurile se declara in mdadm.conf. >>> >> Dar dupa cum vezi, chiar si distributiile cu apa calda nu pot preveni >> inchiderea robinetului :) >> Chestiunile astea sunt scriptate si ele pana la un anumit nivel. De regula >> mergi cand faci matricea pe sistemul respectiv, pentru ca probabil o sa mai >> gasesti inca un mdadm.conf prin initrd-ul ala, ceea ce nu e cazul acum. >> >> Cum dintr-un motiv anume apa calda deocamdata nu curge, incerc sa ii explic >> cum functioneaza. De exemplu daca initrd-ul ala incarca mdadm-ul s-ar putea >> sa >> faca detectia matricilor, si atunci... ghici... in ciuda apei calde, s-ar >> putea sa nu ii pese de /etc/mdadm.conf. In general kernelul nu se uita la >> fisiere din astea. > Ca prima chestie, RHEL 6 ( si implicit CentOS 6 ) include mdadm in initramfs > Iar daca e sa fim mai catolici decit papa, solutia simpla si eleganta > este folosirea optiunii --name in apelul catre mdadm la crearea matricei. > Recomand citirea https://bugzilla.redhat.com/show_bug.cgi?id=606481#c14 > cu accent pe diferenta intre ce se intimpla cind mdadm e rulat la boot > si ce se intimpla cind e rulat ulterior, din linie de comanda. Citez: > "during early boot, when the initramfs is running, the hostname has not > been set yet. As a result, the homehost in the superblock and the > hostname of the machine don't match, mdadm thinks the array is from > another machine, so it is assembled with the hostname prepended to the > array name and using a high md device number." > > Seamana foarte bine ce zice acolo cu ce se intimpla. Chiar am si schimbat hostname , pentru ca am cam schimbat structura acasa . Acesta nu mai e singurul server el va fi in pricipal file server . Acum ma lupt cu alte probleme si nu pot incerca ce ati zis despre oprire si repornire matrice raid. ce ma doare acum cel mai tare e ca inca nu merge interfata usb 3.0 . o sa dau mai multe detalii imediat ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
On 11/16/2013 08:07 PM, Mihai Badici wrote: > On Saturday 16 November 2013 19:49:16 Vali Dragnuta wrote: >> Cam prin toate distributiile cu apa calda s-a convenit de ceva vreme ca >> arrayurile se declara in mdadm.conf. >> > Dar dupa cum vezi, chiar si distributiile cu apa calda nu pot preveni > inchiderea robinetului :) > Chestiunile astea sunt scriptate si ele pana la un anumit nivel. De regula > mergi cand faci matricea pe sistemul respectiv, pentru ca probabil o sa mai > gasesti inca un mdadm.conf prin initrd-ul ala, ceea ce nu e cazul acum. > > Cum dintr-un motiv anume apa calda deocamdata nu curge, incerc sa ii explic > cum functioneaza. De exemplu daca initrd-ul ala incarca mdadm-ul s-ar putea sa > faca detectia matricilor, si atunci... ghici... in ciuda apei calde, s-ar > putea sa nu ii pese de /etc/mdadm.conf. In general kernelul nu se uita la > fisiere din astea. Ca prima chestie, RHEL 6 ( si implicit CentOS 6 ) include mdadm in initramfs Iar daca e sa fim mai catolici decit papa, solutia simpla si eleganta este folosirea optiunii --name in apelul catre mdadm la crearea matricei. Recomand citirea https://bugzilla.redhat.com/show_bug.cgi?id=606481#c14 cu accent pe diferenta intre ce se intimpla cind mdadm e rulat la boot si ce se intimpla cind e rulat ulterior, din linie de comanda. Citez: "during early boot, when the initramfs is running, the hostname has not been set yet. As a result, the homehost in the superblock and the hostname of the machine don't match, mdadm thinks the array is from another machine, so it is assembled with the hostname prepended to the array name and using a high md device number." wolfy ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
On Sat, 2013-11-16 at 19:06 +, Dan Borlovan wrote: > PS: tot in distributiile cu apa calda, montam fs-urile dupa UUID (prietenii > stiu de ce) si nu dupa device, asa ca ni se cam rupe daca e md0, md127 sau > md99 Indeed :) ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
On Sat, 2013-11-16 at 20:25 +0200, Mihai Badici wrote: > On Saturday 16 November 2013 20:16:34 Vali Dragnuta wrote: > > On Sat, 2013-11-16 at 20:07 +0200, Mihai Badici wrote: > > > On Saturday 16 November 2013 19:49:16 Vali Dragnuta wrote: > > > > Cam prin toate distributiile cu apa calda s-a convenit de ceva vreme ca > > > > arrayurile se declara in mdadm.conf. > > > > > > Dar dupa cum vezi, chiar si distributiile cu apa calda nu pot preveni > > > inchiderea robinetului :) > > > > Nu, inchiderea robinetului este cauzata de userul care nu stie cum se > > manevreaza robinetul. > > In lumina faptului ca sistemul se asteapta sa aiba mdadm.conf, devine > > brusc foarte logic ca dupa ce pui setul de discuri intr-o instanta a > > sistemului de operare ce nu le-a mai folosit inainte trebuie sa refaci > > dupa caz mdadm.conf si eventual initrd. > > > > Da, cred ca ambele trebuie refacute, din motivele expuse mai sus. Presupun > insa ca mai intai trebuie sa opreasca md127 si sa o asambleze ca md0, nu sunt > sigur cum face detectia mdadm. Probabil nu a incheiat oficial procesul de migrare, cred ca-si permite un reboot ca sa se asigure ca se asambleaza corect la boot. (Eu chiar as recomanda un reboot final inainte de "go production" ca sa se asigure ca totul se initializeaza cum trebuie in caz de reboot accidental) ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
PS: tot in distributiile cu apa calda, montam fs-urile dupa UUID (prietenii stiu de ce) si nu dupa device, asa ca ni se cam rupe daca e md0, md127 sau md99 ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
> In principiu daca matricea e asamblata de kernel, nu citeste > /etc/mdadm/mdadm.conf. > > In varianta cu initrd inseamna ca tu nu ai compilat in kernel raid-ul, ci il > folosesti ca modul. Presupun ca initrd nu asambleaza decat partitia de boot ( > daca este raid). In cazul asta restul de partitii va fi asamblat in scriptul > de > initializare de mdadm si deci o sa il vada corect, md0 Again, on ubuntu (si unul destul de vechi, eu inca sint pe 10.04 - dar deja avem apa calda de ceva vreme) initrd contine niste "magie" (scripturi) care asambleaza doar aria de boot sau toate ariile, functie de cum e configurat (dpkg --reconfigure mdadm) De fapt, cam multe drivere (inclusiv cele de fs) sint compilate ca module, si nu static in kernel, d-aia avem nevoie de initrd, le ia de acolo si incarca doar cele de care e nevoie. Nu ca in ziua de azi ar fi mare gaura de memorie sa bagi totul static in kernel, da' nu-i frumos. In initrd exista o copie a mdadm.conf, care in mod evident nu se actualizeaza singura, ci doar cind refaci initrd-ul (cu update-initramfs -u) So, nu e nevoie de nici un feli de hackereli de gen demontat si remontat aria in rc.local Ma astept ca orice distributie care a descoperit apa calda sa aiba facilitati similare Dar na, chestie de gusturi, atita timp cit exista rc.local si vrei sa te injure urmatorul sysadmin, poti sa faci ce vrei prin el. Recunosc ca si eu il mai folosesc din cind in cind. Dan ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
din ce imi pare mie, os-ul e pe alte discuri, si chiar daca face upgrade remote o sa se poata loga sa vada ce md device i-a creat kernelul pentru matricea aia si s-o monteze corespunzator. 2013/11/16 Mihai Badici > On Saturday 16 November 2013 20:14:50 Eugeniu Patrascu wrote: > > pana la urma voi acu discutati de o chestie care in afara ca nu-i place > > cuiva numarul 127, nu are nici un impact operational si problema > initiala a > > fost rezolvata. > > > > > Cred ca da :) > Poate exista un oarecare impact, in sensul ca e posibil la un mm dat sa se > milostiveasca cineva si sa introduca in kernel versiunea 1.2, si atunci > dupa > un upgrade de kernel sa aiba o surpriza. > Dar de aia ne-am apucat de linux, nu, ca sa stim de ce se intampla ce se > intampla :) > ___ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug > ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
On Saturday 16 November 2013 20:16:34 Vali Dragnuta wrote: > On Sat, 2013-11-16 at 20:07 +0200, Mihai Badici wrote: > > On Saturday 16 November 2013 19:49:16 Vali Dragnuta wrote: > > > Cam prin toate distributiile cu apa calda s-a convenit de ceva vreme ca > > > arrayurile se declara in mdadm.conf. > > > > Dar dupa cum vezi, chiar si distributiile cu apa calda nu pot preveni > > inchiderea robinetului :) > > Nu, inchiderea robinetului este cauzata de userul care nu stie cum se > manevreaza robinetul. > In lumina faptului ca sistemul se asteapta sa aiba mdadm.conf, devine > brusc foarte logic ca dupa ce pui setul de discuri intr-o instanta a > sistemului de operare ce nu le-a mai folosit inainte trebuie sa refaci > dupa caz mdadm.conf si eventual initrd. > Da, cred ca ambele trebuie refacute, din motivele expuse mai sus. Presupun insa ca mai intai trebuie sa opreasca md127 si sa o asambleze ca md0, nu sunt sigur cum face detectia mdadm. > > > > > ___ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug -- Mihai Bădici http://mihai.badici.ro ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
On Saturday 16 November 2013 20:14:50 Eugeniu Patrascu wrote: > pana la urma voi acu discutati de o chestie care in afara ca nu-i place > cuiva numarul 127, nu are nici un impact operational si problema initiala a > fost rezolvata. > > Cred ca da :) Poate exista un oarecare impact, in sensul ca e posibil la un mm dat sa se milostiveasca cineva si sa introduca in kernel versiunea 1.2, si atunci dupa un upgrade de kernel sa aiba o surpriza. Dar de aia ne-am apucat de linux, nu, ca sa stim de ce se intampla ce se intampla :) ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
On Sat, 2013-11-16 at 20:07 +0200, Mihai Badici wrote: > On Saturday 16 November 2013 19:49:16 Vali Dragnuta wrote: > > Cam prin toate distributiile cu apa calda s-a convenit de ceva vreme ca > > arrayurile se declara in mdadm.conf. > > > > Dar dupa cum vezi, chiar si distributiile cu apa calda nu pot preveni > inchiderea robinetului :) Nu, inchiderea robinetului este cauzata de userul care nu stie cum se manevreaza robinetul. In lumina faptului ca sistemul se asteapta sa aiba mdadm.conf, devine brusc foarte logic ca dupa ce pui setul de discuri intr-o instanta a sistemului de operare ce nu le-a mai folosit inainte trebuie sa refaci dupa caz mdadm.conf si eventual initrd. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
pana la urma voi acu discutati de o chestie care in afara ca nu-i place cuiva numarul 127, nu are nici un impact operational si problema initiala a fost rezolvata. 2013/11/16 Mihai Badici > On Saturday 16 November 2013 19:49:16 Vali Dragnuta wrote: > > Cam prin toate distributiile cu apa calda s-a convenit de ceva vreme ca > > arrayurile se declara in mdadm.conf. > > > > Dar dupa cum vezi, chiar si distributiile cu apa calda nu pot preveni > inchiderea robinetului :) > Chestiunile astea sunt scriptate si ele pana la un anumit nivel. De regula > mergi cand faci matricea pe sistemul respectiv, pentru ca probabil o sa mai > gasesti inca un mdadm.conf prin initrd-ul ala, ceea ce nu e cazul acum. > > Cum dintr-un motiv anume apa calda deocamdata nu curge, incerc sa ii > explic > cum functioneaza. De exemplu daca initrd-ul ala incarca mdadm-ul s-ar > putea sa > faca detectia matricilor, si atunci... ghici... in ciuda apei calde, s-ar > putea sa nu ii pese de /etc/mdadm.conf. In general kernelul nu se uita la > fisiere din astea. > > > > > > > > > > > > ___ > > RLUG mailing list > > RLUG@lists.lug.ro > > http://lists.lug.ro/mailman/listinfo/rlug > -- > Mihai Bădici > http://mihai.badici.ro > ___ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug > ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
On Saturday 16 November 2013 19:49:16 Vali Dragnuta wrote: > Cam prin toate distributiile cu apa calda s-a convenit de ceva vreme ca > arrayurile se declara in mdadm.conf. > Dar dupa cum vezi, chiar si distributiile cu apa calda nu pot preveni inchiderea robinetului :) Chestiunile astea sunt scriptate si ele pana la un anumit nivel. De regula mergi cand faci matricea pe sistemul respectiv, pentru ca probabil o sa mai gasesti inca un mdadm.conf prin initrd-ul ala, ceea ce nu e cazul acum. Cum dintr-un motiv anume apa calda deocamdata nu curge, incerc sa ii explic cum functioneaza. De exemplu daca initrd-ul ala incarca mdadm-ul s-ar putea sa faca detectia matricilor, si atunci... ghici... in ciuda apei calde, s-ar putea sa nu ii pese de /etc/mdadm.conf. In general kernelul nu se uita la fisiere din astea. > > > > ___ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug -- Mihai Bădici http://mihai.badici.ro ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
Cam prin toate distributiile cu apa calda s-a convenit de ceva vreme ca arrayurile se declara in mdadm.conf. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
On Saturday 16 November 2013 19:17:50 Vali Dragnuta wrote: > Trebuie sa refaci mdadm.conf ( cu ceva gen mdadm --examine --scan > > >>newmdadm.conf ) Daca dai mdadm -- stop /dev/md127 si mdadm --start md0 Merge? > > ___ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug -- Mihai Bădici http://mihai.badici.ro ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
On Saturday 16 November 2013 19:17:50 Vali Dragnuta wrote: > Trebuie sa refaci mdadm.conf ( cu ceva gen mdadm --examine --scan > > >>newmdadm.conf ) > Daca lasi kernelul sa construiasca matricea, poti sa refaci de cate ori vrei mdadm.conf, nu foloseste. Mai precis, daca in kernel ai compilat suportul de md ( si nu ai initrd) el va asambla matricea ( si nu va tine cont de mdadm.conf) ; daca insa e asamblata de utilitarul mdadm, va fi asamblata cum trebuie. Teoretic cred ca s-ar putea forta si din udev numele, dar nu am facut asta niciodata, deci nu bag mana in foc. > ___ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug -- Mihai Bădici http://mihai.badici.ro ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
Trebuie sa refaci mdadm.conf ( cu ceva gen mdadm --examine --scan >>newmdadm.conf ) ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
On Saturday 16 November 2013 14:58:43 Dan Borlovan wrote: > > acum asa de design , nu as putea sa-l conving cumva ca device e md0 si > > nu md127 ? > > Nu stiu in centos > > Sun ubuntu trebuie sa fie declarata aria in /etc/mdadm/mdadm.conf > (declaratia ti-o da mdadm --detail --scan) dupa care trebuie actualizat > initrd-ul (update-initramfs -u) In principiu daca matricea e asamblata de kernel, nu citeste /etc/mdadm/mdadm.conf. In varianta cu initrd inseamna ca tu nu ai compilat in kernel raid-ul, ci il folosesti ca modul. Presupun ca initrd nu asambleaza decat partitia de boot ( daca este raid). In cazul asta restul de partitii va fi asamblat in scriptul de initializare de mdadm si deci o sa il vada corect, md0 > ___ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug -- Mihai Bădici http://mihai.badici.ro ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
> acum asa de design , nu as putea sa-l conving cumva ca device e md0 si > nu md127 ? Nu stiu in centos Sun ubuntu trebuie sa fie declarata aria in /etc/mdadm/mdadm.conf (declaratia ti-o da mdadm --detail --scan) dupa care trebuie actualizat initrd-ul (update-initramfs -u) ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
On Saturday 16 November 2013 15:47:23 Paul Lacatus wrote: > On 11.11.2013 17:18, manuel "lonely wolf" wolfshant wrote: > > On 11/11/2013 05:13 PM, Paul Lacatus (Personal) wrote: > >> On 11.11.2013 14:58, Iulian Murgulet wrote: > >>> Quoting Petru Ratiu : > centos 6.4 si reconectat discurile . A recunoscut automat matricea si > mi le-a pus in device /dev/md127. Montat /dev/md127 la locul lui si > totul functioneaza. > > acum asa de design , nu as putea sa-l conving cumva ca device e md0 si > nu md127 ? Cred ca daca nu il lasi sa incarce modulul de md si asamblezi matricea cu mdadm o sa il vada ca md0 Conform celor discutate anterior pe aici- la alt post, kernel-ul nu stie decat de md versiunea 0.9 pe cand mdadm il face by default 1.2 . De exemplu daca il dezasamblezi si il asamblezi la loc cu mdadm o sa iasa md0 . > ___ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug -- Mihai Bădici http://mihai.badici.ro ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
On 11.11.2013 17:18, manuel "lonely wolf" wolfshant wrote: > On 11/11/2013 05:13 PM, Paul Lacatus (Personal) wrote: >> On 11.11.2013 14:58, Iulian Murgulet wrote: >>> Quoting Petru Ratiu : >>> 2013/11/11 Paul Lacatus (Personal) > Am o arie de hard-uri intr-un Raid soft linux . Sunt numai date , nici > una din zonele de lucru linux nu sunt pe aceste discuri . Vreau sa > reinstalez linux-ul fara sa afectez in nici un fel continutul ariei . As > prefera sa le demontez soft , sa le deconectez si sa instalez centos > 6.4 de la zero pe masina care a fost cu FC12. Apoi sa le conectez si > sa le remontez software. > > Credeti ca ar putea aparea probleme? Are cineva un step by step to do ? > > Sarind peste bariera de limbaj (e de apreciat evitarea romglezei, dar incearca sa fii totusi mai specific sa te intelegm si noi astia mai formatati gresit), singura problema pe care o vad este sa nu le incurci la instalare si sa le formatezi. Daca zici ca-s deconectate fizic pe perioada instalarii, nu prea are ce sa nu mearga, driverul de raid software din linux e backwards compatible cu formatele on-disk de la inceputurile inceputurilor. >>> ... pot aparea probleme dupa. Daca ai ghinion(am patit de 2 ori)in 5 >>> ani, si la un moment dat pe discul A(din matricea RAID) sectorul A1 >>> care continut diferit de sectorul B1 de pe discul B(A1 si B1 ar trebui >>> sa fie identice ca si continut), ghici ce se intampla ? Ce date >>> crezi ca vei avea ? >>> Pana afli raspunsul iti doresc un MD cu A1=B1 ;) >>> >>> >>> >> In primul rind raid-ul e 5 asa ca nu prea am continuturi identice intre >> sectoare , si in al doilea rind cind dau demontarea ( umount ) driverul >> nu face mai intii sincronizarea discurilor ? > ba da > am facut sportul asta ( ma rog, chestii similare ) de tz ori. la mine > situatia a fost in general " masina virtuala X are centos N si vreau sa > fac update. asa ca instalez un Centos N+1 ( sau N+2) si montez in el > raid-ul". nu am avut niciodata probleme iar in decursul anilor am tot > trecut centos3/4 la C5/C6 si C5 la C6. > > singura situatie in care pot sa apara probleme este cea in care incerci > sa accesezi raid-ul din o distributie mai veche decit cea in care fost > creat. > done . Deconctat discurile de la interfetele sata , instalat fresh centos 6.4 si reconectat discurile . A recunoscut automat matricea si mi le-a pus in device /dev/md127. Montat /dev/md127 la locul lui si totul functioneaza. acum asa de design , nu as putea sa-l conving cumva ca device e md0 si nu md127 ? ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
> la hdd-uri din cite stiu numarul de biti redundanti si nici nu cred ca > sint informatii care trebuie facute publice : platanele nu sint De la Seagate citire, lungimea codului ECC: 50 de octeti la un sector standard (512 bytes), 100 de octeti la un sector advanced (4096 bytes) http://www.seagate.com/tech-insights/advanced-format-4k-sector-hard-drives-master-ti/ >> Pe noi ne deranjeaza silent corruption - erorile nedetectate - nu erorile >> detectate > Nu inteleg ce vrei sa spui aici. Erorile detectate prin faptul ca iti > crapa o masina sau ai erori in filesystem si trebuie sa intervina fsck Erori detectate - eroare de crc - daca ne referim la hdd, se traduce printr-un read error, crc failed Chiar, am mai avut un caz de silent corruption, "server" facut din desktop, memorie fara ecc, un modul defect si al naibii Murphy, niciodata nu a crapat vreun program, culmea nici coruptie de FS, doar niste mail-uri care treceau prin masina aia aveau atasamentele (arhive) corupte Dan ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
On Sat, 2013-11-16 at 12:23 +, Dan Borlovan wrote: > > --- Prespunind ca ajunge corect acolo.Oricum, nu stim cit de bun este > > acel ECC (16bit, 32 bit...ce algoritm…) > > La mediile magnetice sau optice iti trebe un ecc destul de serios. Mai ales > la densitatea de informatie de acuma (c'mon, 6TB intr-un singur hdd cu 7 > platane… in alte epoci hdd-ul avea 10MB) > > Nu stiu la hdd; la cdrom in mod date ai vreo 276 de octeti (nu biti) de ECC > pentru fiecare 2048 de octeti de date, nu doar 32 de biti de detectie La cdrom da,(cred ca e in standard, si e normal sa fie public si standard astfel ca toate unitatile sa poata citi toate discurile); la hdd-uri din cite stiu numarul de biti redundanti si nici nu cred ca sint informatii care trebuie facute publice : platanele nu sint schimbate, asa ca fiecare producator este liber sa-si rezerve cit considera de cuviinta pentru acel disc in functie de pretul cerut pe disc, garantia oferita si nivelul de activitate pe care il anticipeaza pentru acel model. > > Ideea de aici e nu cit de "bun" e - in sensul cite erori poate corecta - ci > faptul ca exista un mecanism de _detectie_ a erorilor Sigur, dar bun = ce rata de corupere accepta inainte de a fi pacalit (vezi paritatea care poate detecta doar un bit corupt, dupa care intri in zonele in care poti avea date corupte cu paritate corecta). > > Pe noi ne deranjeaza silent corruption - erorile nedetectate - nu erorile > detectate Nu inteleg ce vrei sa spui aici. Erorile detectate prin faptul ca iti crapa o masina sau ai erori in filesystem si trebuie sa intervina fsck sa stearga inozi sau sa mute lanturi in lost+found la mine nu se califica pt "detectie cu succes". Nemaipunind la socoteala ca doar fsck le poate detecta si fsck prin natura sa ruleaza rar. > > Da in 18 ani in zona IT am vazut > - un hdd de desktop care corupea silent datele la scriere, banuiesc ca > memoria de pe el era defecta si nu avea mecanism de detectie a erorilor > - doua laptop-uri care corupeau datele de pe hdd, unul dupa ce bause > cafea/cola, celalalt posibil din cauza ca a stat prea mult pe patura la > caldurica > > Nimic voodoo / cabluri posedate / radiatii cosmice, doar defecte care duc la > coruptie de date in etape in care nu exista paritate/crc/ecc Well,esti fericit atunci :P Eu am vazut ceva mai multe. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
> --- Prespunind ca ajunge corect acolo.Oricum, nu stim cit de bun este > acel ECC (16bit, 32 bit...ce algoritm…) La mediile magnetice sau optice iti trebe un ecc destul de serios. Mai ales la densitatea de informatie de acuma (c'mon, 6TB intr-un singur hdd cu 7 platane… in alte epoci hdd-ul avea 10MB) Nu stiu la hdd; la cdrom in mod date ai vreo 276 de octeti (nu biti) de ECC pentru fiecare 2048 de octeti de date, nu doar 32 de biti de detectie Ideea de aici e nu cit de "bun" e - in sensul cite erori poate corecta - ci faptul ca exista un mecanism de _detectie_ a erorilor Pe noi ne deranjeaza silent corruption - erorile nedetectate - nu erorile detectate Da in 18 ani in zona IT am vazut - un hdd de desktop care corupea silent datele la scriere, banuiesc ca memoria de pe el era defecta si nu avea mecanism de detectie a erorilor - doua laptop-uri care corupeau datele de pe hdd, unul dupa ce bause cafea/cola, celalalt posibil din cauza ca a stat prea mult pe patura la caldurica Nimic voodoo / cabluri posedate / radiatii cosmice, doar defecte care duc la coruptie de date in etape in care nu exista paritate/crc/ecc Dan ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
On Fri, 2013-11-15 at 17:25 +, Dan Borlovan wrote: > Io nu sint in clar cu o chestie > > hdd-ul are ECC (si da il foloseste). Nu stiu daca memoria cache de pe hdd e > si ea macar cu bit de paritate, dar de pe platane erorile de citire sint > detectate (si in masura posibilitatilor corectate) --- Prespunind ca ajunge corect acolo.Oricum, nu stim cit de bun este acel ECC (16bit, 32 bit...ce algoritm...) > > sata are si el ceva crc, ca si sirmele de firma pot avea probleme (asta ca sa > nu ma leg de ingeniosul care a proiectat mufele, care ies afara numai cind te > uiti la ele) --- Da > > memoria dintr-un server e ecc --- Mai exact, de obicei ai paritate, ceea ce inseamna ca-ti corecteaza maxim un bit corect. Tocmai am o masina care logeaza erori de paritate pe un anume bank de memorie si totusi crapa frecvent. Presupun ca dimm-ul e atit de stricat incit inregistreaza deseori coruptii dincolo de bitul corectat de paritate. Shit can happen, easily. BTW, de ce crezi ca sint masini care nu numai ca folosesc memorii ECC, dar au posibilitatea sa implementeze si mirroring de memorie ? Pentru ca uneori e nevoie de mai mult. http://h18000.www1.hp.com/products/servers/technology/memoryprotection.html > > nu stiu memoria cache din controller-ul raid, cel putin unele folosesc > memorii simple de pc, dar la cele profi ma astept sa aiba si ele ecc > > pe ethernet avem si acolo checksum-uri --- Sigur. Dar sint sigur ca stii ca avem ecc in frame-ul ethernet dar avem si checksum (doar pt header,ce-i drept) in header-ul IP si mai avem si in TCP...Pentru ca e clar ca nu doar procesul de transmitere poate provoca erorile ci si eventual procesul de transmisie poate genera erori ci si softwareul prin care trece intre transmisii :) > > Si atunci, exceptind cazuri extreme > - de coruptie intre doua medii de transfer (gen bug in fw la controllerul > raid sau hdd care nu onoreaza un flush de cache) > - modificari care trec de suma de control (ca nah orice algoritm de suma de > control mai scurta decit datele respective va avea coliziuni -> cazuri de > erori nedetectate) > > de unde naiba atitea silent data corruption? --- Sigur, nu zice nimeni ca sint asa frecvente - probabil ca cu cit ai hardware mai scump cu atit mai putine erori ai. Da' guess what, de multe ori hardwareul mai scump isi are rezilienta fix in mecanisme de detectie si corectie a erorilor suplimentare (vezi memory mirroring de mai sus). Am avut masini care erau rebootate normal (deci nu datorita unui crash!) dupa ~180 zile de uptime si fsck.ext3 full gasea mereu si corecta diverse erori minore, in ciuda faptului ca masina nu a avut intreruperi bruste, nu avea probleme cu memoriile etc. De unde ? Probabil ca si de la software bugs si alti factori, daca mai cauti online vei mai gasi diverse referinte. Cert e ca cu cit volumele de date pe care le avem sint mai mari, cu atit probabilitatea de a intilni aceste erori este mai mare. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
Quoting Vali Dragnuta : Pt. fraza asta geniala, care exprima cel mai bine, ideea de baza din topic iti multumesc din tot sufletul! Daca vrei sa testezi zfs, te ajut cu tot ce stiu eu mai bine. > 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). Se pot evita astfel de situatii cred eu(sau se poate reduce impactul). ZFS stie ceva ce se numeste send/recive. Daca ai minim 2 masini cu ZFS, dresezi masina A sa faca snapshoot-ri incrementale din x in x minute(0 downtime, resurse consumate aproape zero, dureaza cateva secunde, de exemplu la un pool cu 1 Tb de date).Apoi de pe A se face send catre B care face receive(e practic un stream de blockuri) pe ce transport vrei tu(ssh,netcat,etc). Evident prima data dureaza mult(daca volumul de date e mare). Eu ma duc cu send/recevie via ssh cam la 7-800 mbits. Daca pool-ul respectiv are activata si compresia(si datetele pe care le pui in pool sunt comprimabile gen fisiere text), volumul de date de transferat se reduce. Alta varianta e faptul ca poti face sapshoot-ri la un intreg pool sau la un data-set anume din acel pool(complet sau incremental, sau combinatii). Eu de exemplu fac cate un snapshot complet saptamanal, si in rest fac incrementale(din 5 in 5 minute, si retin toate snapshot-le din ultimile 48 ore, ultimile 14 zile, ultimile 6 luni). Snapsot-le se pot monta RO sau RW, sau chiar din ele se poate face un roll-back la un pool/data-set intreg. Deci daca se corupe ceva, ai sanse ca sa si recuperezi la o adica. Urmaresc lista de discutii de la zfs-onlinux, cam de aproape un an(cred ca citesc cam 80% din mesajele care apar), dar nu imi aduc aminte, ca careva sa se fi plans ca s-ar fi corupt datele deodata, si in volume mari, incat sa piarda tot, decat in cazuri normale(raid5=raidz, pe 3 HDD-ri, si a pierdut 2 HDD-ri). Nici eu nu exclud totusi ca ar putea exista aceasta varianta. De aceea, cel putin deocamdata, ma asigur asa(sunt toma necredinciosul): - snapshot-ri cum am zis; - send-recive intre masini cu zfs; - update de kernel nu pe toate masinile odata(cate o masina la 3 zile); - backup cu rsnapshot(zilnic, noaptea); - verificari ale pool-lor saptamanal(zfs scrub pool -> erori pe mail) - scripturi care ruleaza din 5/5 minute si-mi trimit erorile care sunt raportate de ZFS(zpool status -v) in timpul operarii ; Deocamdata am mare incredere in ZFS, dovada ca am in regim de productie 8 servere(la clienti diferiti). Motivele pentru care am trecut la ZFS su fost: - managementul extraordinar si detailat la nivel de volum manager(quota, compresie, rezervare de spatiu), si partea de snapshot. - folosesc multe montari separate, deci am aplicatii/servicii pe propriul file-sistem sau block-device(fiecare container openvz pe un block-device separat formatat ext4, samba pe un data-set=FS nativ ZFS, squid, samd) - am sisteme cu 20-30 de data-set-ri, fiecare cu proprietati potrivite pt. acel serviciu(la FS-ul de squid, am activata compresia, la niste containere KVM bazate pe win nu am compresie activata, la un container openvz care are mysql am /var/lib/mysql recordsize=8K (ZFS default is 128k), samd). Eu folosesc / am in ograda in general servere no-name, achizitonate pe criteriul pret, si cu probleme la curentul electric(spatamanal pica curentul, in special iarna si toamna). De fapt sunt desktop-ri mai rasarite, cu HDD-ri de tip desktop(nu green). Aveam md raid1, si mi se intampla des(1 data la 2 luni/sistem), sa-mi iasa din raid discuri-le. Si al mano', le bagam din nou, si asteptam cateva ore pana se re-sincronizau(si o resincronizare in timpul zilei insemna telefoane ca "merge incet copierea pe ..."). Acum pe ZFS nu mai am problema asta. Am clienti care isi sterg des fisiere(inclusiv mail-ri), si apoi le vor inapoi(le restaurez din snapshot). Am testat si asa: masina cu ZFS, reinstalat SO, pus suport de zfs, datele au ramas si au fost OK. Am luat disc-ri cu ZFS, si le-am montat pe alta masina, cu ZFS, am avut datele OK Din tot ce am zis eu, nu inseamna ca ZFS-ul nu are probleme, are in special pe partea de performanta. Dar si aici se poate imbunati situatia, daca bagi un SSD(folosit pe post de cache de citire, in stilul squid). Nu are viteze extraordinare la scriere. As zice ca este acceptabil, in special acolo unde sunt date compresibile(baze de date, care fiind text se comprima f. bine). Uite o "inginerie" facuta pe ZFS, care mi-ar fi luat o groaza de timp pe altceva: - aveam un ZFS cu mirror(2 disk-ri); - am trecut de la mirror la raidz(3 disk-ri, rid5 cu paritate); - apoi am trecut de la raidz la raidz2(4 disk-ri, raid5 cu paritate dubla); Scuze daca te-am plictisit, si inca odata MULTUMESC. Daca treci prin
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
Quoting Vali Dragnuta : > 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). Exact. Verificare se face automat la utilizare normala, fara sa-i faci ceva special. > 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. Exact si asta. > 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. Exact. > > 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). NU are fsck. Tot ce scrie pe disk se scrie in tranzactii. Dupa ce datele au ajuns pe platane, se adauga metadatele. E de tip CopyOnWrite. Am testat pe un HDD pe USB. Scris/modificat/redenumit fisiere, oprit curentul la usb, pornit, verificat. Cateva ore in total, datele erau cum trebe. Ce nu apuca sa scrie complet, nu apare in FS. > 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. > Corect. > 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). Folosesc de 2 ani zfs-fuse, pe 7-8 masini(samba, mail-ri, squid, gluster, openvz - toate peste zfs, cu file system zfs, sau zfs exporta un block-device formatat de ex. ext4) Eu nu am avut probleme, nu am vazut rateuri. De juma de an folosesc modul de kernel pe cam 6 masini si un laptop. Cam pe toate distributiile(centos/redhat,debian/ubuntu), ai rmp-ri/deb-ri care se recompileaza automat via dkms. Iarasi nici aici nu am avut probleme. Nici pe debian nici pe centos si nici pe ubuntu. > 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. > Exact la asta m-am gandit si eu. Wikipedia: "ZFS is a combined file system and logical volume manager designed by Sun Microsystems. The features of ZFS include protection against data corruption, support for high storage capacities, efficient data compression, integration of the concepts of filesystem and volume management, snapshots and copy-on-write clones, continuous integrity checking and automatic repair, RAID-Z and native NFSv4 ACLs. Data integrity One major feature that distinguishes ZFS from other file systems is that ZFS is designed with a focus on data integrity. That is, it is designed to protect the user's data on disk against silent data corruption caused by bit rot, current spikes, bugs in disk firmware, phantom writes (the write is dropped on the floor), misdirected reads/writes (the disk accesses the wrong block), DMA parity errors between the array and server memory or from the driver (since the checksum validates data inside the array), driver errors (data winds up in the wrong buffer inside the kernel), accidental overwrites (such as swapping to a live file system), etc. Error rates in hard
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
Io nu sint in clar cu o chestie hdd-ul are ECC (si da il foloseste). Nu stiu daca memoria cache de pe hdd e si ea macar cu bit de paritate, dar de pe platane erorile de citire sint detectate (si in masura posibilitatilor corectate) sata are si el ceva crc, ca si sirmele de firma pot avea probleme (asta ca sa nu ma leg de ingeniosul care a proiectat mufele, care ies afara numai cind te uiti la ele) memoria dintr-un server e ecc nu stiu memoria cache din controller-ul raid, cel putin unele folosesc memorii simple de pc, dar la cele profi ma astept sa aiba si ele ecc pe ethernet avem si acolo checksum-uri Si atunci, exceptind cazuri extreme - de coruptie intre doua medii de transfer (gen bug in fw la controllerul raid sau hdd care nu onoreaza un flush de cache) - modificari care trec de suma de control (ca nah orice algoritm de suma de control mai scurta decit datele respective va avea coliziuni -> cazuri de erori nedetectate) de unde naiba atitea silent data corruption? -- Dan Borlovan Datagroup-Int ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
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 > > > > > > > ... 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) > > > >
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
On Fri, 15 Nov 2013, Iulian Murgulet wrote: > - cred ca ai citit in altceva, eu nu am zis ca RAID-ul "trebe sa faca > teste de memorie" Pai n-ai zis nici ca trebuie sa stearga praful, nu ma bucur ca n-ai inteles aluzia. >> Pai despre ce discutam? Pina acum te plingeai de detectia erorilor >> care apar pe disc in timp, eventual cu discurile oprite, dind exemplul >> ala cu CERN sau cu data anus rupturition. > > ... si discurile transfera datele prin telepatie cu aplicatiile? La > mine, discurile cheap sunt legate cu cabluri! Nu, dar ca si la retele exista mai multe nivele pe care circula datele. Mai multe layere. Unele sint responsabile cu unele lucruri, altele sint responsabile cu altele. >> nivelele, de la driver de controller raid, implementarea raid din formware >> (sau modul kernel unde e soft), pina la discul insusi. > > - de facut fac toate, dar dar le mai si scapa unele erori! Pai toate fac in felul lor aceasta detectie a erorilor, incepind de la integritatea magnetica si impartirea logica a suprafetei. > - am ras-explicat, eu nu am pretentia ca explic f. bine, > dar cred gasesti tu pe net explicatii detailate despre ZFS pe partea asta, > fara incurcaturi de layere; Da, sa nu ne mai incurcam cu layere. Sa bagam pe acelasi nivel filesystemul, volume managerul, matricile raid, discul, si suruburile de la platan. >> Vezi la ce neintelegeri ajungem daca vorbesti neclar, te referi la >> un lucru si vrei sa spui altul, sau incurci termenii si layerele unui >> subansamblu? FAIL! Asta e real time data curruption. > > - chiar nu ma intereseaza cum ii zice! Pai daca tie nu-ti pasa de termeni cum vrei sa ai o discutie tehnica si precisa cu cineva? Gesticulind de parca te-ai inecat cu un mar? > "Este datoria lor" - a cui? Pai nu mai conteaza. Cred ca a conectorilor SATA, ca oricum ai zis ca vrei sa ai totul la acelasi layer. >> Err, signature FAIL follows...: ^^ x 2: > > 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 > > == > -- I'm a genuine network and sys admin. I swear, I curse, I stick my dick into things in order to fix them. So don't ack like you're having a bad day with me around, 'cause I'll have fix to you and will not be able to fight it! ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
On Fri, 15 Nov 2013, Iulian Murgulet wrote: > 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. Mai adu LVM in discutie si compara-l cu RAID doar pentru ca are sripes si mirrors si gata, ne putem zvirli toti de pe geam. -- I'm a genuine network and sys admin. I swear, I curse, I stick my dick into things in order to fix them. So don't ack like you're having a bad day with me around, 'cause I'll have fix to you and will not be able to fight it! ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
On 11/15/2013 02:45 PM, Mișu Moldovan wrote: > 2013/11/15 Tarhon-Onu Victor : >>Vezi la ce neintelegeri ajungem daca vorbesti neclar, te referi la >> un lucru si vrei sa spui altul, sau incurci termenii si layerele unui >> subansamblu? FAIL! Asta e real time data curruption. > Freudian slip or what? e voita. vino si tu pe #mumu , stai suficient si o sa pricepi cum sta treaba ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
2013/11/15 Tarhon-Onu Victor : > Vezi la ce neintelegeri ajungem daca vorbesti neclar, te referi la > un lucru si vrei sa spui altul, sau incurci termenii si layerele unui > subansamblu? FAIL! Asta e real time data curruption. Freudian slip or what? Nu mă întreb așa mult cine-i Ion cel rupt în fund, da' totuși cum se întâmplă asta în timp real?!? :) Hhmmm... ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
Quoting Andrei Pascal : > 2013/11/15 Iulian Murgulet > >> Quoting Andrei Pascal : >> >> > 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? >> >> ... on-demand >> > > C?t de des? Cum te asiguri c? l-ai rulat FIX înainte s? apar? orice > posibil? corup?ie? Dac? datele s-au corupt înainte s? rulezi scrub-ul? > Ca regula generala, saptamanal. Si care e ideea ca nu inteleg? Daca datele sunt corupte, ZFS-ul va incerca sa le corecteze daca poate. Dar nu asta e esential, ci faptul ca pot afla asta(ca am date corupte, recuperabile sau nu)! > >> > Dac? îl rulezi la >> > scriere ?i cu asta basta, nu e nici o diferen?? între ZFS ?i RAID 5 de >> > exemplu. >> >>Ba da este. ZFS nu are "RAID-5 write hole"! >> >> Ok, fie cum zici tu. > > >> > 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 >> >> ... iar restul e poveste ? >> > > Vezi mai sus... > > >> > î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. >> > >> >> ... nu ma intereseaza. Merge in productie si la mine si la alte case mai >> mari. > > > M? bucur doar c? nu stau în Bra?ov, pe partea rela?iei mele cu statul > mult-iubit. ?i sper c? datele despre mine nu sunt ?inute pe acele ma?ini, > c? n-o s? am nici o pl?cere în a alerga pentru a le reface când acel ZFS o > va lua prin copaci. Stai linistit. Esti sigur ca numa ZFS o ia prin copaci? De ceva timp sa inventat si backup-ul! > ___ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug > 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 00.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 RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
Quoting Tarhon-Onu Victor : > On Fri, 15 Nov 2013, Iulian Murgulet wrote: > >> ... nu cred ca exprimarile "ne-elegante", ca sa fiu diplomat, >> intarasc argumentele! Mai cred ca respectul si bunul-simt ajuta mai >> mult! > > Imi pare rau dar peste un anumit threshold de batut cimpii nu ma > mai pot abtine. Imi cer scuze pentru iesirile din trecut si respectiv > anticipat pentru iesirile viitoare, pentru ca fiind moldovean... > http://www.youtube.com/watch?v=YUz5XDERIt8 > (Ala din clip nu-s eu, era sa fiu eu insa l-a facut asta primul). > >> Raid soft am folosit de mai bine de 10 ani, pe mai mult de o masina. >> Folosesc si acum md raid1 pe partitiile cu sistemul de operare. Eu am >> scris ca md raid1 nu e cea mai buna solutie pe partitiile de date, si am >> sugerat dupa parerea mea, o solutie mai buna, evident conform cu lipsa >> mea de experienta! > > Wow! pe 2 masini! Cu discuri luate de la acelasi chiosc in > acelasi timp, scapate jos in aceeasi cutie la transport! Nu pe asa multe, au fost doar 1.5 masini. Discurile mi-au venit intotdeana parasutate dintr-un satelit, si aia de le parasuteaza folosesc pungi de la super-market, nu le pun in cutii! > Eu nu te-am contrazis cind ai spus ca raid nus' de care nu e cea > mai buna pentru nus' ce partitii, ci te-am combatut cind ai inceput sa ai > pretentii de la implementarea raid sa faca teste de memorie pe masina, sa > verifice daca e sters praful si daca se aprind toate ledurile la masina > de uscat miinile din WC. - cred ca ai citit in altceva, eu nu am zis ca RAID-ul "trebe sa faca teste de memorie" > >>... cum am mai precizat anterior, altii au alta parere. Ei cred >> ca e treaba >> partii de control/management a array-ui sa detecteze erorile(in >> anumite conditii) si sa le si repare din informatiile de >> redundanta(daca exista date suficiente). > > Orice astfel de implentare va face detectie de erori pe datele CU > CARE LUCREAZA. Datele odata ajunse pe disc, daca discul o ia razna in > portiuni pe care kernelul nu le atinge din diverse motive. > In momentul in care intr-o matrice raid cu redundanta se vor face > citiri ale unui bloc de cate si nu corespund informatiile de pe discuri - la MD raid1, cu ce sa corespunda daca el citeste blocul fara eroare - dar ce a citit nu e identic cu ce am scris? > (mirror/normal, checksum, etc) atunci fii sigur ca raid-ul va sari in sus > si va incepe sa zbiare ca a gasit ceva. Dar altfel, daca datele stau acolo > si nu le scrie/citeste nimeni e ca si cum ai avea discurile in sertar si > ai vrea sa-si dea cineva seama ca e ceva in neregula. > >> Nu trebuie sa si fii de acord cu solutia asta. Si de ce ma rog nu as >> putea sa folosesc md raid pe discuri cheap? RAID tocmai asta insemna: >> redundant array of inexpensive disks. Tu te referi la RAE(xpensive)D, >> nu-i asa? > > Cheap sau Expensive detectia si tratarea erorilor se face la > nivele diferite in situatii diferite, sau in puncte similare pentru > situatii similare. Poate sa difere doar cit de adinc se intra in structura > matricii sau a discurilor pentru asa ceva. > Vei vedea adaptoare RAID de la diversi vendori, in valoare de > multe sute de dolari sau chiar trec mia, la care detectia erorilor pe disc > se rezuma la monitorizari SMART (si uneori nici atit!!) cu exceptia > cazurilor cind sint erori la scrieri/citiri. Restul cade in seama > software-ului de SAN sau a sistemelor de fisiere de pe partitiile facute > pe acele array-uri. > Sau vei vedea adaptoare care cind apar erori (pentru ca stau mai > bine la partea asta) o iau razna cind apare ceva mai nasol pentru ca stau > sa rontaie ele si sa ia tot felul de decizii sa compenseze iar in camera > alaturata vei vedea 5 sisadmini facind concurs de dat cu capul in zid ca > nu pot opri procesul ca sa se termine 5 tranzactii bancare la timp intr-un > cluster de 1M$. > Deja nu mai vorbim de solutii cheap ci de solutii unde un singur > sistem membru al unui cluster costa peste 10k$. Si nu exista implementare > ideala din diverse motive, exista doar solutii care se preteaza mai bine > pentru o situatie sau alta. > >> Da. Ia sa vedem ce zici tu, poate iarasi nu inteleg eu si-mi >> scapa ceva. Caz >> concret: am 12 Tb de date, cu 'jde milioane de fisiere, si scriu >> cam 1Tb/24h. >> Cam cat ar dura sa fac verificari de md5sum/sha1sum? Si sa creez >> altele la fisierele modificate/adaugate? Dar tot nu ma ajuta cand >> citesc, pt. ca nu stiu >> daca ce citesc e asa cum a fost scris sau nu. Si daca in loc de 12 Tb, >> am 120Tb? >> Alt caz, cablu sATA prost: SMART zice OK, dar aleator > > Pai despre ce discutam? Pina acum te plingeai de detectia erorilor > care apar pe disc in timp, eventual cu discurile oprite, dind exemplul > ala cu CERN sau cu data anus rupturition. ... si discurile transfera datele prin telepatie cu aplicatiile? La mine, discurile cheap sunt legate cu cabluri! > Ca detectie a erorilor in timp real fac
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
2013/11/15 Iulian Murgulet > Quoting Andrei Pascal : > > > 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? > > ... on-demand > Căt de des? Cum te asiguri că l-ai rulat FIX înainte să apară orice posibilă corupție? Dacă datele s-au corupt înainte să rulezi scrub-ul? > > Dac? îl rulezi la > > scriere ?i cu asta basta, nu e nici o diferen?? între ZFS ?i RAID 5 de > > exemplu. > >Ba da este. ZFS nu are "RAID-5 write hole"! > > Ok, fie cum zici tu. > > 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 > > ... iar restul e poveste ? > Vezi mai sus... > > î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. > > > > ... nu ma intereseaza. Merge in productie si la mine si la alte case mai > mari. Mă bucur doar că nu stau în Brașov, pe partea relației mele cu statul mult-iubit. Și sper că datele despre mine nu sunt ținute pe acele mașini, că n-o să am nici o plăcere în a alerga pentru a le reface când acel ZFS o va lua prin copaci. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
Quoting Andrei Pascal : > 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? ... on-demand > Dac? îl rulezi la > scriere ?i cu asta basta, nu e nici o diferen?? între ZFS ?i RAID 5 de > exemplu. Ba da este. ZFS nu are "RAID-5 write hole"! > 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 ... iar restul e poveste ? > î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. > ... nu ma intereseaza. Merge in productie si la mine si la alte case mai mari. > > 2013/11/15 Iulian Murgulet > >> >> >> ... 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 >> RLUG@lists.lug.ro >> http://lists.lug.ro/mailman/listinfo/rlug >> > > > > -- > Ave > http://flying.prwave.ro > ___ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug > 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 00.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 RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
Quoting Tarhon-Onu Victor : > On Fri, 15 Nov 2013, Iulian Murgulet wrote: > >> - cand scrie un bloc de date, sa scrie si un check-sum pt. acel bloc, iar >> cand citesc, un block de date sa-i calculez check-sum-ul si sa-l compar cu >> check-sum-ul stocat la scriere; > > Si cum/cind faci asta? E ceva ce se intimpla in mod activ sau > on-demand? Ambele. Se intampla activ cand fac scrieri/citiri, dar daca vreau pot face o verificare on-demand, la un intreg pool! > >> - nu am pomenit nimic de hw raid; > > Pai ce relevanta are? Data curruption apare la nivel de disc, tu > vrei ca raid-ul sa ia masuri. Nici o implementare raid nu va face asta in > mod activ. Ba face ZFS-ul. Poate sa apara si in RAM, in chipset, in CPU, practic oriunde. > > -- > I'm a genuine network and sys admin. > I swear, I curse, I stick my dick into things in order to fix them. > So don't ack like you're having a bad day with me around, > 'cause I'll have fix to you and will not be able to fight it! > ___ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug > 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 RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
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 > > > ... 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 > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug > -- Ave http://flying.prwave.ro ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
... 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 RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
On Fri, 15 Nov 2013, Iulian Murgulet wrote: >>> E la fel de bun? ca un software RAID. > > Cine? MD-ul e la fel de bun ca un hw RAID - asta ai vrut sa zici? Din puntul de vedere al performantei nu. Din punctul de vedere al raportului performanta/pret e mai bun software raid. Din punctul de vedere al tratarii erorilor si a fiabilitatii pot aparea discutii. Nu rare cind cazurile cind intr-o matrice raid se duce in lumea ei adaptorul raid si varzuieste datele pe discurile care nu au nimic. La un software raid daca se intimpla asta vei vedea un kernel panic cu mult inainte ca datele de pe array sa fie inutilizabile. Implementarile RAID hardware insa nu pot fi inlocuite cu implementari software pentru array-uri mari. Chiar si cu CPU puternic si mult RAM, performantele unei matrici de, sa zicem, 32 de discuri sit mult sub acelasi array implementat cu un controller dedicat. Insa chiar si in situatii dintr-astea extreme, daca scopul pentru care ai nevoie de aceasta implementare nu e unul neaparat critic, sau este dar performanta nu e critica si diferenta reala nu va fi mare pentru ca te poti baza pe plusul consistent de viteza rezultat din mecanismele de caching de date atunci deciziile vor fi dificil de luat. Implementarile RAID hardware sint cumva echivalentul medicamentelor "naturiste" de purificare pentru traiul nesanatos. Zilele trecute am fost fortat sa ascult vreo 30 de secunde un post de radio si era o proasta care spunea ceva de genul: "ficatul tau sufera de la consumul de alcool, tutun, si de la oboseala? Acum exista nu_stiu_ce_cacat, otraveste-te sistematic cu asta sa ajuti organismul sa elimine". Ei, daca ai nevoie ca sistemul tau sa traiasca in conditii dificile (necesar de performante mari in mod sustinut) atunci baga-i medicamentul hardware. Altfel nu-l forta/indopa aiurea cu cacaturi daca nu e nevoie. -- I'm a genuine network and sys admin. I swear, I curse, I stick my dick into things in order to fix them. So don't ack like you're having a bad day with me around, 'cause I'll have fix to you and will not be able to fight it! ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
2013/11/15 Iulian Murgulet > Quoting Andrei Pascal : > > >> > Si pentru orice altceva exista md5sum/sha1sum. Daca ceva se duce > >> > la vale vei vedea folosind astfel de utilitare indiferent de mediul pe > >> > care sint datele. > >> > >>Da. Ia sa vedem ce zici tu, poate iarasi nu inteleg eu si-mi scapa > >> ceva. Caz > >> concret: am 12 Tb de date, cu 'jde milioane de fisiere, si scriu cam > >> 1Tb/24h. > >> Cam cat ar dura sa fac verificari de md5sum/sha1sum? Si sa creez > >> altele la fisierele modificate/adaugate? Dar tot nu ma ajuta cand > >> citesc, pt. ca nu stiu > >> daca ce citesc e asa cum a fost scris sau nu. Si daca in loc de 12 Tb, > >> am 120Tb? > >> > > > > Deci tu aici propui ca controller-ul s? ?i citeasc? înapoi ceea ce a > scris, > > nu? Eu asta în?eleg. > > NU. Pt. orice BLOCK scris, sa am un check-sum stocat pe disk pt. acel > block. > > Țeapă. Discurile au această facilitate implementată în hardware. Orice mediu magnetic include - intern, în controller și stocat pe același mediu - niște chestii numite coduri detectoare și corectoare de erori. Valabil și la benzile digitale, și la discuri. Doar că astea nu se văd din afara mediului cu pricina (la portul SATA/SAS/FC/whatever). Iar RAID-urile cu paritate (5,6, 50,60 etc) exact asta și fac. Ceea ce vrei tu se face mult mai simplu, cu RAID 1. Calculul unui super checksum în timp real costă - d-aia RAID5 și RAID6 sunt lente ca porcu'. > > > > > > >>Alt caz, cablu sATA prost: SMART zice OK, dar aleator > >> > >> > > SMART nu mai apuc? s? zic? nimic, c? ?i se umplu logurile sistem mult > > înainte de SMART dac? ai un cablu prost. > > NU. Nu apare nimic in LOG-ri legat de asta. > > > > Dar, scuz?-m?, parc? vorbeam de > > sistem de produc?ie (care în general trebuie s? fie foarte fiabile), nu > de > > calculatoare f?cute pe genunchi "s? ias? eftin, c? ?i-a?a pl?tim > > curentu'... ", sau gre?esc? Deci ce caut? un cablu PROST într-un sistem > de > > produc?ie?! > > > > Nu asta e discutia, ce cauta cablul ala acolo. > > Ba din păcate e, pentru că dacă n-ai avea HW făcut pe vapor în furtună n-ai sta să reinventezi roata și apa caldă cu 30 de sisteme de corecție de erori unul peste altul. Conectica nu trebuie să-ți creeze probleme, doar vorbim de un setup critic, nu? > > > > >> > >> > Si gindeste-te cite instalari de OS sint pe RAID, daca s-ar duce > >> > ceva la vale iti dai seama ca intr-un final masinile alea ar boota cu > >> > spatele, nu? Ah, dar stai, tu nu gindesti, doar crezi ce ai citit "pe > >> > internet"! > >> > > >> > >>Oare asa sa fie? Toti bat campii? Si astia cu ZFS, BTRFS, > >> ext4(metadata checksumming), XFS(metadata checksums)? Alt caz, cablu > >> sATA defect la un moment dat: SMART zice OK, dar aleator ZFS scrub > >> zice ca a detectat erori, si > >> a corectat acele erori(4 din 8 teste, 2 teste/24 ore). Schimbat cablul > >> eSATA, > >> erorile au disparut de atunci. Si mai sunt si alte fenomene din astea > >> ezoterice(controler disk/RAM/samd)! Aici m-ar fi ajutat cu ceva md-ul > >> sau sumele de control md5sum/sha1sum calculate? Cand as fi aflat? > >> > >>De fapt eu asta am vrut sa zic(poate nu m-am exprimat cum trebe): > >> - md raid nu e prost; > >> - md raid nu e cea mai buna solutie d.p.d.v. al detectiei/corectiei > >> erorilor(erori care pot sa apara din N directii si care nu sunt > >> imputabile > >> lui MD: disk,RAM,echipamente,incompetenta,etc,etc); > >> > > > > E la fel de bun? ca un software RAID. > > > > > >> - ZFS este superior ca si capabilitatiti legate de detectie/corectie > erori > >> fata de MD; > >> > > > > ...doar c? ZFS e o combina?ie de volume management + filesystem, adic? > tot > > la RAID ajungem. > > Si ce daca? Prinde soareci si sobolani animalu'? Ii prinde. Ce importanta > are ca blana e cu albastru si verde! Tu zici cam asa, nu e buna decat > pisica > care e de culoare neagra, dar care prinde doar soareci! > > Din anumite motive (despre care nu discutăm aici) ZFS nu beneficiază de suport (comercial) decât în implementarea de Solaris. Pe Linux mai grei. Și revenim la mediile de producție. > > > > > >> - ca e treaba lui MD sau nu, ca faca detectie de erori si sa le si > >> corecteze(intr-un mod care sa nu presupuna eforturi deosebite, gen > >> calcul de > >> sume de control pe milioane de fisiere si/sau zeci de Tb de date), > >> cred ca e un aspect pur filozofic, si in nici un caz nu e ceva > >> pragmatic. > >> > >> > > E foarte pragmatic: md / RAID-ul NU V?D FI?IERE ci doar blocuri de > alocare > > consituite din grupuri de sectoare pe discurile fizice. Niciodat? > > controller-ul RAID (HW sau SW) nu o s? fac? checksum la contentul unui > > fi?ier. > > > > - nu la fisiere, la block-ri de disk > Vezi mai sus, asta face discul în interior și, în afară, RAID-urile 5, 6, 50, 60 etc. Cu consum de CPU. Care poate fi al sistemului sau al controller-ului raid. Care duc la penalizări de performanță care, se pare, nu îți sunt suficiente. :) -- Ave http://flying.pr
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
On Fri, 15 Nov 2013, Iulian Murgulet wrote: > - cand scrie un bloc de date, sa scrie si un check-sum pt. acel bloc, iar > cand citesc, un block de date sa-i calculez check-sum-ul si sa-l compar cu > check-sum-ul stocat la scriere; Si cum/cind faci asta? E ceva ce se intimpla in mod activ sau on-demand? > - nu am pomenit nimic de hw raid; Pai ce relevanta are? Data curruption apare la nivel de disc, tu vrei ca raid-ul sa ia masuri. Nici o implementare raid nu va face asta in mod activ. -- I'm a genuine network and sys admin. I swear, I curse, I stick my dick into things in order to fix them. So don't ack like you're having a bad day with me around, 'cause I'll have fix to you and will not be able to fight it! ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
On Fri, 15 Nov 2013, Iulian Murgulet wrote: > ... nu cred ca exprimarile "ne-elegante", ca sa fiu diplomat, > intarasc argumentele! Mai cred ca respectul si bunul-simt ajuta mai > mult! Imi pare rau dar peste un anumit threshold de batut cimpii nu ma mai pot abtine. Imi cer scuze pentru iesirile din trecut si respectiv anticipat pentru iesirile viitoare, pentru ca fiind moldovean... http://www.youtube.com/watch?v=YUz5XDERIt8 (Ala din clip nu-s eu, era sa fiu eu insa l-a facut asta primul). > Raid soft am folosit de mai bine de 10 ani, pe mai mult de o masina. > Folosesc si acum md raid1 pe partitiile cu sistemul de operare. Eu am > scris ca md raid1 nu e cea mai buna solutie pe partitiile de date, si am > sugerat dupa parerea mea, o solutie mai buna, evident conform cu lipsa > mea de experienta! Wow! pe 2 masini! Cu discuri luate de la acelasi chiosc in acelasi timp, scapate jos in aceeasi cutie la transport! Eu nu te-am contrazis cind ai spus ca raid nus' de care nu e cea mai buna pentru nus' ce partitii, ci te-am combatut cind ai inceput sa ai pretentii de la implementarea raid sa faca teste de memorie pe masina, sa verifice daca e sters praful si daca se aprind toate ledurile la masina de uscat miinile din WC. >... cum am mai precizat anterior, altii au alta parere. Ei cred ca e treaba > partii de control/management a array-ui sa detecteze erorile(in > anumite conditii) si sa le si repare din informatiile de > redundanta(daca exista date suficiente). Orice astfel de implentare va face detectie de erori pe datele CU CARE LUCREAZA. Datele odata ajunse pe disc, daca discul o ia razna in portiuni pe care kernelul nu le atinge din diverse motive. In momentul in care intr-o matrice raid cu redundanta se vor face citiri ale unui bloc de cate si nu corespund informatiile de pe discuri (mirror/normal, checksum, etc) atunci fii sigur ca raid-ul va sari in sus si va incepe sa zbiare ca a gasit ceva. Dar altfel, daca datele stau acolo si nu le scrie/citeste nimeni e ca si cum ai avea discurile in sertar si ai vrea sa-si dea cineva seama ca e ceva in neregula. > Nu trebuie sa si fii de acord cu solutia asta. Si de ce ma rog nu as > putea sa folosesc md raid pe discuri cheap? RAID tocmai asta insemna: > redundant array of inexpensive disks. Tu te referi la RAE(xpensive)D, > nu-i asa? Cheap sau Expensive detectia si tratarea erorilor se face la nivele diferite in situatii diferite, sau in puncte similare pentru situatii similare. Poate sa difere doar cit de adinc se intra in structura matricii sau a discurilor pentru asa ceva. Vei vedea adaptoare RAID de la diversi vendori, in valoare de multe sute de dolari sau chiar trec mia, la care detectia erorilor pe disc se rezuma la monitorizari SMART (si uneori nici atit!!) cu exceptia cazurilor cind sint erori la scrieri/citiri. Restul cade in seama software-ului de SAN sau a sistemelor de fisiere de pe partitiile facute pe acele array-uri. Sau vei vedea adaptoare care cind apar erori (pentru ca stau mai bine la partea asta) o iau razna cind apare ceva mai nasol pentru ca stau sa rontaie ele si sa ia tot felul de decizii sa compenseze iar in camera alaturata vei vedea 5 sisadmini facind concurs de dat cu capul in zid ca nu pot opri procesul ca sa se termine 5 tranzactii bancare la timp intr-un cluster de 1M$. Deja nu mai vorbim de solutii cheap ci de solutii unde un singur sistem membru al unui cluster costa peste 10k$. Si nu exista implementare ideala din diverse motive, exista doar solutii care se preteaza mai bine pentru o situatie sau alta. > Da. Ia sa vedem ce zici tu, poate iarasi nu inteleg eu si-mi scapa ceva. Caz > concret: am 12 Tb de date, cu 'jde milioane de fisiere, si scriu cam 1Tb/24h. > Cam cat ar dura sa fac verificari de md5sum/sha1sum? Si sa creez > altele la fisierele modificate/adaugate? Dar tot nu ma ajuta cand > citesc, pt. ca nu stiu > daca ce citesc e asa cum a fost scris sau nu. Si daca in loc de 12 Tb, > am 120Tb? > Alt caz, cablu sATA prost: SMART zice OK, dar aleator Pai despre ce discutam? Pina acum te plingeai de detectia erorilor care apar pe disc in timp, eventual cu discurile oprite, dind exemplul ala cu CERN sau cu data anus rupturition. Ca detectie a erorilor in timp real face cam oricine pe toate nivelele, de la driver de controller raid, implementarea raid din formware (sau modul kernel unde e soft), pina la discul insusi. > Oare asa sa fie? Toti bat campii? Si astia cu ZFS, BTRFS, > ext4(metadata checksumming), XFS(metadata checksums)? Alt caz, cablu > sATA defect la un moment dat: SMART zice OK, dar aleator ZFS scrub > zice ca a detectat erori, si Erorile din metadata sint mai usor de detectat, pentru ca partea aia a sistemului de fisiere este citita/scrisa mai des, si este mult mai mica (de obicei incape in RAM) si poate fi verificata in citeva secunde chiar daca FS-ul in s
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
Quoting Andrei Pascal : > 2013/11/15 Andrei Pascal > >> >> 2013/11/15 Iulian Murgulet >> >>> Quoting Tarhon-Onu Victor : >>> >>> >>>De fapt eu asta am vrut sa zic(poate nu m-am exprimat cum trebe): >>> - md raid nu e prost; >>> - md raid nu e cea mai buna solutie d.p.d.v. al detectiei/corectiei >>> erorilor(erori care pot sa apara din N directii si care nu sunt >>> imputabile >>> lui MD: disk,RAM,echipamente,incompetenta,etc,etc); >>> >> >> E la fel de bun? ca un software RAID. Cine? MD-ul e la fel de bun ca un hw RAID - asta ai vrut sa zici? >> >> > > Am vrut s? zic "hardware RAID", scuze pentru eroare. > > -- > Ave > http://flying.prwave.ro > ___ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug > 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 RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
Quoting Andrei Pascal : > 2013/11/15 Iulian Murgulet > >> Quoting Tarhon-Onu Victor : >> >> > On Thu, 14 Nov 2013, Iulian Murgulet wrote: >> > >> >> Ma indoiesc ca aia de la CERN umbla cu "discuri varza", sau "green". >> > >> > Tu crezi ce vrei, eu doar imi fac datoria sa-ti spun care-i >> > realitatea ca sa nu ramii cu impresia ca ce se intimpla intr-un sistem de >> > calcul e cumva magie neagra, sau ca justificarile oficiale ale unora >> > pentru niste erori timpite si greu de imaginat la fondurile pe care le au >> > si masurile pe care ar trebui sa le ia pentru prevenire sint deja baza de >> > studiu stiintific. >> > Ai avut si tu un array software raid in 5 ani cu discuri de >> > 2ROL/bax care ti-a crapat si acum gata, ai acumulat experienta care-ti >> > spune ca software raid-ul e de cacat. Serios! >> >>... nu cred ca exprimarile "ne-elegante", ca sa fiu diplomat, >> intarasc argumentele! Mai cred ca respectul si bunul-simt ajuta mai >> mult! >> >> Raid soft am folosit >> de mai bine de 10 ani, pe mai mult de o masina. Folosesc si acum md >> raid1 pe partitiile cu sistemul de operare. Eu am scris ca md raid1 nu >> e cea mai buna solutie pe partitiile de date, si am sugerat dupa >> parerea mea, o solutie mai >> buna, evident conform cu lipsa mea de experienta! >> > > S?-?i spun c? pe ma?ini de milioane $ care ?in date de zeci/sute de > milioane $ se folosesc RAID 1 ?i/sau RAID 5 SOFTWARE în Linux cu filesystem > ext3... sau s? nu-?i spun? S?-?i mai spun c? în europa (NUMAI în Europa!) > sunt câteva mii de asemenea ma?ini, doar de la un vendor anume? Neah, mai > bine nu-?i spun. > > >> >> >> > >> > Probabil ca nu intelegi nici despre ce relatezi aici. Ce legatura >> > are raid-ul software sau hardware sau mistiqueware daca datele de pe un >> > disc se duc in lumea lor? >> >> ... si ce ar trebui sa inteleg? >> >> > Nu e job-ul partii de control si management a array-ului sa-si dea >> > seama ce se intimpla pe un disc cu datele atita timp cit ele nu trec prin >> > BUS/interfata. E treaba partii de management a discului sa-si dea seama >> ca >> > discul de 2ROL/bax e cu vaca iar tu sa folosesti un soft de monitorizare >> > periodica a semnalelor de la SMART care sa te atentioneze ca >> > cheap&reliable=FAIL. >> >> ... cum am mai precizat anterior, altii au alta parere. Ei cred ca e >> treaba >> partii de control/management a array-ui sa detecteze erorile(in >> anumite conditii) si sa le si repare din informatiile de >> redundanta(daca exista date suficiente). Nu trebuie sa si fii de acord >> cu solutia asta. Si de ce ma rog nu >> as putea sa folosesc md raid pe discuri cheap? RAID tocmai asta >> insemna: redundant array of inexpensive disks. Tu te referi la >> RAE(xpensive)D, nu-i asa? >> > > Controller-ul nu face writethrough pe disc, c? merge pe ideea c? discul e > de încredere. Dac? discul NU e de încredere, nici un controller n-o s? > poat? preveni coruperea datelor. AAA, dac? tu vrei s? ?i cite?ti > imediat dup? ce ai scris, s? vedem ce impact are asta asupra urm?torului > paragraf: > > >> >> > >> > Si pentru orice altceva exista md5sum/sha1sum. Daca ceva se duce >> > la vale vei vedea folosind astfel de utilitare indiferent de mediul pe >> > care sint datele. >> >>Da. Ia sa vedem ce zici tu, poate iarasi nu inteleg eu si-mi scapa >> ceva. Caz >> concret: am 12 Tb de date, cu 'jde milioane de fisiere, si scriu cam >> 1Tb/24h. >> Cam cat ar dura sa fac verificari de md5sum/sha1sum? Si sa creez >> altele la fisierele modificate/adaugate? Dar tot nu ma ajuta cand >> citesc, pt. ca nu stiu >> daca ce citesc e asa cum a fost scris sau nu. Si daca in loc de 12 Tb, >> am 120Tb? >> > > Deci tu aici propui ca controller-ul s? ?i citeasc? înapoi ceea ce a scris, > nu? Eu asta în?eleg. NU. Pt. orice BLOCK scris, sa am un check-sum stocat pe disk pt. acel block. > > >>Alt caz, cablu sATA prost: SMART zice OK, dar aleator >> >> > SMART nu mai apuc? s? zic? nimic, c? ?i se umplu logurile sistem mult > înainte de SMART dac? ai un cablu prost. NU. Nu apare nimic in LOG-ri legat de asta. > Dar, scuz?-m?, parc? vorbeam de > sistem de produc?ie (care în general trebuie s? fie foarte fiabile), nu de > calculatoare f?cute pe genunchi "s? ias? eftin, c? ?i-a?a pl?tim > curentu'... ", sau gre?esc? Deci ce caut? un cablu PROST într-un sistem de > produc?ie?! > Nu asta e discutia, ce cauta cablul ala acolo. > >> >> > Si gindeste-te cite instalari de OS sint pe RAID, daca s-ar duce >> > ceva la vale iti dai seama ca intr-un final masinile alea ar boota cu >> > spatele, nu? Ah, dar stai, tu nu gindesti, doar crezi ce ai citit "pe >> > internet"! >> > >> >>Oare asa sa fie? Toti bat campii? Si astia cu ZFS, BTRFS, >> ext4(metadata checksumming), XFS(metadata checksums)? Alt caz, cablu >> sATA defect la un moment dat: SMART zice OK, dar aleator ZFS scrub >> zice ca a detectat erori, si >> a corectat acele erori(4 din 8 teste, 2 teste/24 ore). Schimbat cablul
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
Quoting Tarhon-Onu Victor : > On Thu, 14 Nov 2013, Iulian Murgulet wrote: > >> Eu nu am sugerat ca e din cauza RAID-lui. Eu cred ca e menirea >> RAID-ui sa le corecteze daca poate(parerea mea proprie), si mai cred >> deasemenea ca cel putin ar trebui sa ma anunte sau sa-mi dea o comanda >> ca sa verific datele, care sa-mi zica ceva de genul si exemplific pt. >> md RAID1(tot dupa mine FAKE-RAID1): >> "Bai fraiere, vezi ca ai sectoare oglindite care au continut >> diferit, si e posibil sa ai probleme. Sectoare respective afecteaza >> fisierele X,Y,.. din calea /..., sau afecteaza metadatele " > > Pai odata scrise datele SI verificate la scriere pe toti membrii > matricii (vorbim de implementarile redundante) tu cine crezi ca ar trebui > sa mai ruleze inca o ferificare destul de costisitoare dpdv. al I/O cind > poate sistemul ala ruleaza niste tranzactii critice? - am scris ca nu e solutia perfecta > Ar trebui sa se apuce implementarea RAID sa rupa discurile in > bucati intimplator fix in mijlocul unui eveniment critic sau asta ar > trebui sa fie parte a unui proces de mentenanta (de asta multe > implementari hardware raid au optiuni pentru verificarea discurilor)? > - cand scrie un bloc de date, sa scrie si un check-sum pt. acel bloc, iar cand citesc, un block de date sa-i calculez check-sum-ul si sa-l compar cu check-sum-ul stocat la scriere; > Tot o dai pe asta cu fake raid, nu prea inteleg la ce te referi > sincer sa fiu, pentru ca implementarea de software raid e cit se poate de > similara cu cele hardware raid cu diferenta ca la implementarile hardware > raid se ocupa altcineva de I/O, sume de control (era sa zic checksumuri, > probabil declansam un cocktet de atacuri aeriene cu asta), shiftari pe > biti acolo unde datele se scriu in oglinda, samd. - nu am pomenit nimic de hw raid; > >> Si uite ca mai sunt si altii care au avut tot ideea asta >> "ezoterica", ca adminul sa stie daca sunt astfel de situatii: >> ZFS(mirror,raidz). Mai mult aia de au conceput ZFS, au zis ca e treaba >> RAID-ui sa corecteze on-the-fly(daca am suficienta informatie >> redundanta) situatiile in care am erori la ce citesc(ce citesc de pe >> disc/pool e diferit de ce am scris pe disc/pool). Si au facut si >> comanda: > > Ce legatura are implementarea de FS cu cea de RAID? De ce ar fi > proasta implementarea RAID (dupa tine toate ar fi proaste) pentru ca nu > face si chestii pe care le fac anumite sisteme de fisiere? - nu am pomenit nimic de FS, nici ca ar fi ceva legat de FS. In ZFS pot sa am alocata o zona de blocuri de disk pe care sa pun ce FS vreau eu(similar cu LVM), extX,ntfs, sau sa-l export catre un iSCSI(export un block-device si nu un fisier)! > Serios acuma, masina ta de spalat ar trebui sa faca 0-100 in 10-15 > secunde doar ca sa fie demna de termenul "masina" sau indatorirea ei este > sa stea cumintica in portbagaj pina o duci acasa si-o fixezi de un perete > unde iti va spala tone de rufe pe care masina cealalta a ta care face > 0-100 in 10-15 secunde nu ti le va putea spala? > > >> zpool scrub un-pool-de-discuri-varza >> ... si dupa ce termina de verificat "varza" imi zice: > > Pfaii... niste comenzi pe care nu le-am rulat si nu le voi rula > niciodata...!! Ma gindesc oare de ce... > Foarte bine, fiecare cu optiunea lui! > -- > I'm a genuine network and sys admin. > I swear, I curse, I stick my dick into things in order to fix them. > So don't ack like you're having a bad day with me around, > 'cause I'll have fix to you and will not be able to fight it! > ___ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug > 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 RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
2013/11/15 Andrei Pascal > > 2013/11/15 Iulian Murgulet > >> Quoting Tarhon-Onu Victor : >> >> >>De fapt eu asta am vrut sa zic(poate nu m-am exprimat cum trebe): >> - md raid nu e prost; >> - md raid nu e cea mai buna solutie d.p.d.v. al detectiei/corectiei >> erorilor(erori care pot sa apara din N directii si care nu sunt >> imputabile >> lui MD: disk,RAM,echipamente,incompetenta,etc,etc); >> > > E la fel de bună ca un software RAID. > > Am vrut să zic "hardware RAID", scuze pentru eroare. -- Ave http://flying.prwave.ro ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
2013/11/15 Iulian Murgulet > Quoting Tarhon-Onu Victor : > > > On Thu, 14 Nov 2013, Iulian Murgulet wrote: > > > >> Ma indoiesc ca aia de la CERN umbla cu "discuri varza", sau "green". > > > > Tu crezi ce vrei, eu doar imi fac datoria sa-ti spun care-i > > realitatea ca sa nu ramii cu impresia ca ce se intimpla intr-un sistem de > > calcul e cumva magie neagra, sau ca justificarile oficiale ale unora > > pentru niste erori timpite si greu de imaginat la fondurile pe care le au > > si masurile pe care ar trebui sa le ia pentru prevenire sint deja baza de > > studiu stiintific. > > Ai avut si tu un array software raid in 5 ani cu discuri de > > 2ROL/bax care ti-a crapat si acum gata, ai acumulat experienta care-ti > > spune ca software raid-ul e de cacat. Serios! > >... nu cred ca exprimarile "ne-elegante", ca sa fiu diplomat, > intarasc argumentele! Mai cred ca respectul si bunul-simt ajuta mai > mult! > > Raid soft am folosit > de mai bine de 10 ani, pe mai mult de o masina. Folosesc si acum md > raid1 pe partitiile cu sistemul de operare. Eu am scris ca md raid1 nu > e cea mai buna solutie pe partitiile de date, si am sugerat dupa > parerea mea, o solutie mai > buna, evident conform cu lipsa mea de experienta! > Să-ți spun că pe mașini de milioane $ care țin date de zeci/sute de milioane $ se folosesc RAID 1 și/sau RAID 5 SOFTWARE în Linux cu filesystem ext3... sau să nu-ți spun? Să-ți mai spun că în europa (NUMAI în Europa!) sunt câteva mii de asemenea mașini, doar de la un vendor anume? Neah, mai bine nu-ți spun. > > > > > > Probabil ca nu intelegi nici despre ce relatezi aici. Ce legatura > > are raid-ul software sau hardware sau mistiqueware daca datele de pe un > > disc se duc in lumea lor? > > ... si ce ar trebui sa inteleg? > > > Nu e job-ul partii de control si management a array-ului sa-si dea > > seama ce se intimpla pe un disc cu datele atita timp cit ele nu trec prin > > BUS/interfata. E treaba partii de management a discului sa-si dea seama > ca > > discul de 2ROL/bax e cu vaca iar tu sa folosesti un soft de monitorizare > > periodica a semnalelor de la SMART care sa te atentioneze ca > > cheap&reliable=FAIL. > > ... cum am mai precizat anterior, altii au alta parere. Ei cred ca e > treaba > partii de control/management a array-ui sa detecteze erorile(in > anumite conditii) si sa le si repare din informatiile de > redundanta(daca exista date suficiente). Nu trebuie sa si fii de acord > cu solutia asta. Si de ce ma rog nu > as putea sa folosesc md raid pe discuri cheap? RAID tocmai asta > insemna: redundant array of inexpensive disks. Tu te referi la > RAE(xpensive)D, nu-i asa? > Controller-ul nu face writethrough pe disc, că merge pe ideea că discul e de încredere. Dacă discul NU e de încredere, nici un controller n-o să poată preveni coruperea datelor. AAA, dacă tu vrei să și citești imediat după ce ai scris, să vedem ce impact are asta asupra următorului paragraf: > > > > > Si pentru orice altceva exista md5sum/sha1sum. Daca ceva se duce > > la vale vei vedea folosind astfel de utilitare indiferent de mediul pe > > care sint datele. > >Da. Ia sa vedem ce zici tu, poate iarasi nu inteleg eu si-mi scapa > ceva. Caz > concret: am 12 Tb de date, cu 'jde milioane de fisiere, si scriu cam > 1Tb/24h. > Cam cat ar dura sa fac verificari de md5sum/sha1sum? Si sa creez > altele la fisierele modificate/adaugate? Dar tot nu ma ajuta cand > citesc, pt. ca nu stiu > daca ce citesc e asa cum a fost scris sau nu. Si daca in loc de 12 Tb, > am 120Tb? > Deci tu aici propui ca controller-ul să și citească înapoi ceea ce a scris, nu? Eu asta înțeleg. >Alt caz, cablu sATA prost: SMART zice OK, dar aleator > > SMART nu mai apucă să zică nimic, că ți se umplu logurile sistem mult înainte de SMART dacă ai un cablu prost. Dar, scuză-mă, parcă vorbeam de sistem de producție (care în general trebuie să fie foarte fiabile), nu de calculatoare făcute pe genunchi "să iasă eftin, că și-așa plătim curentu'... ", sau greșesc? Deci ce caută un cablu PROST într-un sistem de producție?! > > > Si gindeste-te cite instalari de OS sint pe RAID, daca s-ar duce > > ceva la vale iti dai seama ca intr-un final masinile alea ar boota cu > > spatele, nu? Ah, dar stai, tu nu gindesti, doar crezi ce ai citit "pe > > internet"! > > > >Oare asa sa fie? Toti bat campii? Si astia cu ZFS, BTRFS, > ext4(metadata checksumming), XFS(metadata checksums)? Alt caz, cablu > sATA defect la un moment dat: SMART zice OK, dar aleator ZFS scrub > zice ca a detectat erori, si > a corectat acele erori(4 din 8 teste, 2 teste/24 ore). Schimbat cablul > eSATA, > erorile au disparut de atunci. Si mai sunt si alte fenomene din astea > ezoterice(controler disk/RAM/samd)! Aici m-ar fi ajutat cu ceva md-ul > sau sumele de control md5sum/sha1sum calculate? Cand as fi aflat? > >De fapt eu asta am vrut sa zic(poate nu m-am exprimat cum trebe): > - md raid nu e prost; > - md raid nu e cea
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
Quoting Tarhon-Onu Victor : > On Thu, 14 Nov 2013, Iulian Murgulet wrote: > >> Ma indoiesc ca aia de la CERN umbla cu "discuri varza", sau "green". > > Tu crezi ce vrei, eu doar imi fac datoria sa-ti spun care-i > realitatea ca sa nu ramii cu impresia ca ce se intimpla intr-un sistem de > calcul e cumva magie neagra, sau ca justificarile oficiale ale unora > pentru niste erori timpite si greu de imaginat la fondurile pe care le au > si masurile pe care ar trebui sa le ia pentru prevenire sint deja baza de > studiu stiintific. > Ai avut si tu un array software raid in 5 ani cu discuri de > 2ROL/bax care ti-a crapat si acum gata, ai acumulat experienta care-ti > spune ca software raid-ul e de cacat. Serios! ... nu cred ca exprimarile "ne-elegante", ca sa fiu diplomat, intarasc argumentele! Mai cred ca respectul si bunul-simt ajuta mai mult! Raid soft am folosit de mai bine de 10 ani, pe mai mult de o masina. Folosesc si acum md raid1 pe partitiile cu sistemul de operare. Eu am scris ca md raid1 nu e cea mai buna solutie pe partitiile de date, si am sugerat dupa parerea mea, o solutie mai buna, evident conform cu lipsa mea de experienta! > > Probabil ca nu intelegi nici despre ce relatezi aici. Ce legatura > are raid-ul software sau hardware sau mistiqueware daca datele de pe un > disc se duc in lumea lor? ... si ce ar trebui sa inteleg? > Nu e job-ul partii de control si management a array-ului sa-si dea > seama ce se intimpla pe un disc cu datele atita timp cit ele nu trec prin > BUS/interfata. E treaba partii de management a discului sa-si dea seama ca > discul de 2ROL/bax e cu vaca iar tu sa folosesti un soft de monitorizare > periodica a semnalelor de la SMART care sa te atentioneze ca > cheap&reliable=FAIL. ... cum am mai precizat anterior, altii au alta parere. Ei cred ca e treaba partii de control/management a array-ui sa detecteze erorile(in anumite conditii) si sa le si repare din informatiile de redundanta(daca exista date suficiente). Nu trebuie sa si fii de acord cu solutia asta. Si de ce ma rog nu as putea sa folosesc md raid pe discuri cheap? RAID tocmai asta insemna: redundant array of inexpensive disks. Tu te referi la RAE(xpensive)D, nu-i asa? > > Si pentru orice altceva exista md5sum/sha1sum. Daca ceva se duce > la vale vei vedea folosind astfel de utilitare indiferent de mediul pe > care sint datele. Da. Ia sa vedem ce zici tu, poate iarasi nu inteleg eu si-mi scapa ceva. Caz concret: am 12 Tb de date, cu 'jde milioane de fisiere, si scriu cam 1Tb/24h. Cam cat ar dura sa fac verificari de md5sum/sha1sum? Si sa creez altele la fisierele modificate/adaugate? Dar tot nu ma ajuta cand citesc, pt. ca nu stiu daca ce citesc e asa cum a fost scris sau nu. Si daca in loc de 12 Tb, am 120Tb? Alt caz, cablu sATA prost: SMART zice OK, dar aleator > Si gindeste-te cite instalari de OS sint pe RAID, daca s-ar duce > ceva la vale iti dai seama ca intr-un final masinile alea ar boota cu > spatele, nu? Ah, dar stai, tu nu gindesti, doar crezi ce ai citit "pe > internet"! > Oare asa sa fie? Toti bat campii? Si astia cu ZFS, BTRFS, ext4(metadata checksumming), XFS(metadata checksums)? Alt caz, cablu sATA defect la un moment dat: SMART zice OK, dar aleator ZFS scrub zice ca a detectat erori, si a corectat acele erori(4 din 8 teste, 2 teste/24 ore). Schimbat cablul eSATA, erorile au disparut de atunci. Si mai sunt si alte fenomene din astea ezoterice(controler disk/RAM/samd)! Aici m-ar fi ajutat cu ceva md-ul sau sumele de control md5sum/sha1sum calculate? Cand as fi aflat? De fapt eu asta am vrut sa zic(poate nu m-am exprimat cum trebe): - md raid nu e prost; - md raid nu e cea mai buna solutie d.p.d.v. al detectiei/corectiei erorilor(erori care pot sa apara din N directii si care nu sunt imputabile lui MD: disk,RAM,echipamente,incompetenta,etc,etc); - ZFS este superior ca si capabilitatiti legate de detectie/corectie erori fata de MD; - ca e treaba lui MD sau nu, ca faca detectie de erori si sa le si corecteze(intr-un mod care sa nu presupuna eforturi deosebite, gen calcul de sume de control pe milioane de fisiere si/sau zeci de Tb de date), cred ca e un aspect pur filozofic, si in nici un caz nu e ceva pragmatic. > P.S.: CERN is derutatii aia care au primit foarte multi bani sa faca cu > accelerator de particule dar aveau cabluri de retea ranforsate cu banda > izolatoare, cu mufe de 2ROL/camion, care faceau contact imperfect si peste > care foloseau nus' ce protocol proprietar cu un control mai putin strict > al erorilor de li s-au varzuit toate datele strinse la prima activare a > acceleratorului? Am inteles, is incompetenti astia de la CERN. Dar mai exista si altii care au publicat rapoarte similare. Sa intelg ca absolut toti sunt incompetenti? Sa inteleg ca de fapt tu afirmi ca: in conditii NORMALE de exploatare, cu echipamante mai mult decat decente, cu personal nu compete
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
> tehnic e corect ce spui. practic exista > - cu controler dedicat ( cu procesor, memorie si preferabil baterie > proprie ) == raid hardware > - cu implementare software de raid la nivel de BIOS + driver pt OS > provenit de la fabricantul placii (!) == fakeraid > - cu implementare software de raid la nivel de OS ( ex: mdadm ) == raid > software > > cu mentiunea ca de obicei mai bine iti bagi picioarele in driverul de fake-raid, si faci un raid soft de la mama lui pe linux, ca procesorul va face la fel de mult 'fitness', si scapi de crap-ul de drivere obscure pentru mai stiu eu ce placi aiurea de 'raid' (vezi supermicro) Alex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
On 11/15/2013 10:54 AM, Paul Lacatus (Personal) wrote: > On 15.11.2013 08:51, Tarhon-Onu Victor wrote: >> Tot o dai pe asta cu fake raid, nu prea inteleg la ce te referi sincer >> sa fiu, pentru ca implementarea de software raid e cit se poate de >> similara cu cele hardware raid cu diferenta ca la implementarile >> hardware raid se ocupa altcineva de I/O, sume de control (era sa zic >> checksumuri, probabil declansam un cocktet de atacuri aeriene cu >> asta), shiftari pe biti acolo unde datele se scriu in oglinda, samd. > Eu nu inteleg ce diferenta este intre implementare "Hardware" de raid > si "Software" . Corect este cu controler dedicat sau fara controller > dedicat . tehnic e corect ce spui. practic exista - cu controler dedicat ( cu procesor, memorie si preferabil baterie proprie ) == raid hardware - cu implementare software de raid la nivel de BIOS + driver pt OS provenit de la fabricantul placii (!) == fakeraid - cu implementare software de raid la nivel de OS ( ex: mdadm ) == raid software > Chiar daca e un controler dedicat raid , asa cum s-a spus si > mai sus, el face exact aceleasi > lucruri ca si implementarea cu procesorul si controlerul I/O al > calculatorului insa o face separat fara sa consume resursele > calculatorului si transparent pentru SO . Din experienta mea si cu un > tip si altul nu am avut probleme de date corupte decit o singura data > cind conform legilor lui Murphy doua discuri au picat la diferenta de > 1/2 ora dintr-un raid 5 soft cu 4 discuri la care avea voie sa pice doar > unul . mie mi-au picat simultan 3 barracuda din cele 4 ( raid 10 ) ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
On 15.11.2013 08:51, Tarhon-Onu Victor wrote: > Tot o dai pe asta cu fake raid, nu prea inteleg la ce te referi sincer > sa fiu, pentru ca implementarea de software raid e cit se poate de > similara cu cele hardware raid cu diferenta ca la implementarile > hardware raid se ocupa altcineva de I/O, sume de control (era sa zic > checksumuri, probabil declansam un cocktet de atacuri aeriene cu > asta), shiftari pe biti acolo unde datele se scriu in oglinda, samd. Eu nu inteleg ce diferenta este intre implementare "Hardware" de raid si "Software" . Corect este cu controler dedicat sau fara controller dedicat . Chiar daca e un controler dedicat raid , asa cum s-a spus si mai sus, el face exact aceleasi lucruri ca si implementarea cu procesorul si controlerul I/O al calculatorului insa o face separat fara sa consume resursele calculatorului si transparent pentru SO . Din experienta mea si cu un tip si altul nu am avut probleme de date corupte decit o singura data cind conform legilor lui Murphy doua discuri au picat la diferenta de 1/2 ora dintr-un raid 5 soft cu 4 discuri la care avea voie sa pice doar unul . ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
On Thu, 14 Nov 2013, Iulian Murgulet wrote: > Eu nu am sugerat ca e din cauza RAID-lui. Eu cred ca e menirea > RAID-ui sa le corecteze daca poate(parerea mea proprie), si mai cred > deasemenea ca cel putin ar trebui sa ma anunte sau sa-mi dea o comanda > ca sa verific datele, care sa-mi zica ceva de genul si exemplific pt. > md RAID1(tot dupa mine FAKE-RAID1): > "Bai fraiere, vezi ca ai sectoare oglindite care au continut > diferit, si e posibil sa ai probleme. Sectoare respective afecteaza > fisierele X,Y,.. din calea /..., sau afecteaza metadatele " Pai odata scrise datele SI verificate la scriere pe toti membrii matricii (vorbim de implementarile redundante) tu cine crezi ca ar trebui sa mai ruleze inca o ferificare destul de costisitoare dpdv. al I/O cind poate sistemul ala ruleaza niste tranzactii critice? Ar trebui sa se apuce implementarea RAID sa rupa discurile in bucati intimplator fix in mijlocul unui eveniment critic sau asta ar trebui sa fie parte a unui proces de mentenanta (de asta multe implementari hardware raid au optiuni pentru verificarea discurilor)? Tot o dai pe asta cu fake raid, nu prea inteleg la ce te referi sincer sa fiu, pentru ca implementarea de software raid e cit se poate de similara cu cele hardware raid cu diferenta ca la implementarile hardware raid se ocupa altcineva de I/O, sume de control (era sa zic checksumuri, probabil declansam un cocktet de atacuri aeriene cu asta), shiftari pe biti acolo unde datele se scriu in oglinda, samd. > Si uite ca mai sunt si altii care au avut tot ideea asta > "ezoterica", ca adminul sa stie daca sunt astfel de situatii: > ZFS(mirror,raidz). Mai mult aia de au conceput ZFS, au zis ca e treaba > RAID-ui sa corecteze on-the-fly(daca am suficienta informatie > redundanta) situatiile in care am erori la ce citesc(ce citesc de pe > disc/pool e diferit de ce am scris pe disc/pool). Si au facut si > comanda: Ce legatura are implementarea de FS cu cea de RAID? De ce ar fi proasta implementarea RAID (dupa tine toate ar fi proaste) pentru ca nu face si chestii pe care le fac anumite sisteme de fisiere? Serios acuma, masina ta de spalat ar trebui sa faca 0-100 in 10-15 secunde doar ca sa fie demna de termenul "masina" sau indatorirea ei este sa stea cumintica in portbagaj pina o duci acasa si-o fixezi de un perete unde iti va spala tone de rufe pe care masina cealalta a ta care face 0-100 in 10-15 secunde nu ti le va putea spala? > zpool scrub un-pool-de-discuri-varza > ... si dupa ce termina de verificat "varza" imi zice: Pfaii... niste comenzi pe care nu le-am rulat si nu le voi rula niciodata...!! Ma gindesc oare de ce... -- I'm a genuine network and sys admin. I swear, I curse, I stick my dick into things in order to fix them. So don't ack like you're having a bad day with me around, 'cause I'll have fix to you and will not be able to fight it! ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
On Thu, 14 Nov 2013, Iulian Murgulet wrote: > Ma indoiesc ca aia de la CERN umbla cu "discuri varza", sau "green". Tu crezi ce vrei, eu doar imi fac datoria sa-ti spun care-i realitatea ca sa nu ramii cu impresia ca ce se intimpla intr-un sistem de calcul e cumva magie neagra, sau ca justificarile oficiale ale unora pentru niste erori timpite si greu de imaginat la fondurile pe care le au si masurile pe care ar trebui sa le ia pentru prevenire sint deja baza de studiu stiintific. Ai avut si tu un array software raid in 5 ani cu discuri de 2ROL/bax care ti-a crapat si acum gata, ai acumulat experienta care-ti spune ca software raid-ul e de cacat. Serios! Probabil ca nu intelegi nici despre ce relatezi aici. Ce legatura are raid-ul software sau hardware sau mistiqueware daca datele de pe un disc se duc in lumea lor? Nu e job-ul partii de control si management a array-ului sa-si dea seama ce se intimpla pe un disc cu datele atita timp cit ele nu trec prin BUS/interfata. E treaba partii de management a discului sa-si dea seama ca discul de 2ROL/bax e cu vaca iar tu sa folosesti un soft de monitorizare periodica a semnalelor de la SMART care sa te atentioneze ca cheap&reliable=FAIL. Si pentru orice altceva exista md5sum/sha1sum. Daca ceva se duce la vale vei vedea folosind astfel de utilitare indiferent de mediul pe care sint datele. Si gindeste-te cite instalari de OS sint pe RAID, daca s-ar duce ceva la vale iti dai seama ca intr-un final masinile alea ar boota cu spatele, nu? Ah, dar stai, tu nu gindesti, doar crezi ce ai citit "pe internet"! P.S.: CERN is derutatii aia care au primit foarte multi bani sa faca cu accelerator de particule dar aveau cabluri de retea ranforsate cu banda izolatoare, cu mufe de 2ROL/camion, care faceau contact imperfect si peste care foloseau nus' ce protocol proprietar cu un control mai putin strict al erorilor de li s-au varzuit toate datele strinse la prima activare a acceleratorului? Vai "CERN"!, ce pompos suna, cred ca-si si competenti, nu? Vai, sint in elvetia! Automat au IQ 450 si la citi bani au cred ca fac asta doar din pasiune, din geniu, si nu au grija zilei de miine! Vai, sa-i facem dumnezeii array-urilor RAID si sa credem orice spun ei ca sa-si justifice pierderile financiare, faptul ca restul oamenilor sint politicosi si lasa varzetul povestit de ei asa cum e si nu-l mai corecteaza din politete si din simpla acordare a inca unei sanse face totul si mai credibil si ne da motive in plus sa credem ce spun ei, ba chiar sa facem o noua teorie a conspiratiei be baza afirmatiilor alora! Vai, CERN! Brr!!! Bai du-te de aici... -- I'm a genuine network and sys admin. I swear, I curse, I stick my dick into things in order to fix them. So don't ack like you're having a bad day with me around, 'cause I'll have fix to you and will not be able to fight it! ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
Quoting Tarhon-Onu Victor : > > Fiecare disc parte dintr-o matrice (sau arie, uvertura, cocktet > sau cum vrei tu sa-l botezi aici) RAID (hopa! pentru RAID nu ai > echivalentul purrromanesc? Baga si tu ceva, "atac aerian" de exemplu) are > prin primele sectoare diverse informatii cu privire la array-ul (na!!) > raid din care face parte. > Daca la reinstalare nu repartitionezi acele discuri sau nu > formatezi fortat partitiile membre atunci nu vei avea probleme. > > Minunile alea ezoterice de genul "silent data curruption" si alte > misticisme de genul se intimpla in niste situatii specifice, de exemplu > discuri varza sau greenFAIL exploatate ca si unele sanatoase la cap, sau > ecranate necorespunzator pentru acel tip de disc si mediul in care sint > exploatate, sau discuri care au ramas fara sectoare de relocare insa nu se > uita nici mutu' cum urla ele acolo in sinea lor prin SMART. Ma indoiesc ca aia de la CERN umbla cu "discuri varza", sau "green". > Poti incerca sa lasi telefonul mobil pe carcasa unui server zi de > zi si dupa citeva saptamini/luni e posibil (dar nu neaparat, trebuie sa > fie si carcasa aiurea, si discul, etc) sa vezi minuni pe discuri. E doar > un exemplu. Alte probleme mai pot aparea cu discurile care sint foarte > aproape de tunere TV, de sursele PC, samd. Dar nu apar din cauza > RAID-ului, si nici nu e menirea implementarilor RAID sa le corecteze. > Eu nu am sugerat ca e din cauza RAID-lui. Eu cred ca e menirea RAID-ui sa le corecteze daca poate(parerea mea proprie), si mai cred deasemenea ca cel putin ar trebui sa ma anunte sau sa-mi dea o comanda ca sa verific datele, care sa-mi zica ceva de genul si exemplific pt. md RAID1(tot dupa mine FAKE-RAID1): "Bai fraiere, vezi ca ai sectoare oglindite care au continut diferit, si e posibil sa ai probleme. Sectoare respective afecteaza fisierele X,Y,.. din calea /..., sau afecteaza metadatele " Si uite ca mai sunt si altii care au avut tot ideea asta "ezoterica", ca adminul sa stie daca sunt astfel de situatii: ZFS(mirror,raidz). Mai mult aia de au conceput ZFS, au zis ca e treaba RAID-ui sa corecteze on-the-fly(daca am suficienta informatie redundanta) situatiile in care am erori la ce citesc(ce citesc de pe disc/pool e diferit de ce am scris pe disc/pool). Si au facut si comanda: zpool scrub un-pool-de-discuri-varza ... si dupa ce termina de verificat "varza" imi zice: zpool status pool: un-pool-de-discuri-varza state: ONLINE scan: scrub repaired 0 in 2h44m with 0 errors on Sun Nov 10 02:45:01 2013 config: NAME STATE READ WRITE CKSUM un-pool-de-discuri-varza ONLINE 0 0 0 raidz2-0ONLINE 0 0 0 scsi-SATA_varza_olteneasca ONLINE 0 0 0 scsi-SATA_varza_moldovineasca ONLINE 0 0 0 scsi-SATA_varza_ardeleneasca ONLINE 0 0 0 scsi-SATA_varza_banateana ONLINE 0 0 0 errors: No known data errors Nu zic ca e varianta perfecta, dar cu siguranta, e mai bine sa stiu ca datele mele erau "asa cum au fost scrise candva" in data de Nov 10 02:45:01 2013, sau din contra, ca am o problema si atunci primul lucru pe care il incerc e sa-mi schimb cablurile de date sATA(numa anul asta am inlocuit o duzina). > Problemele cu matricile raid la distributii mai noi sau mai vechi > au cam disparut undeva prin 2002-2003 cred, nu mai tin minte versiunea de > kernel dar cred ca eram inca la 2.4.x (2.4.21?). La vremea respectiva > trebuia refacut array-ul fortat, mentinindu-se aceiasi parametri (tip, > chunk size, etc) si dupa refacere daca nu dadeai cu tirnacopul in discuri > inainte aveai toate datele intacte. Cred ca tocmai se trecea la mdadm in > perioada aia, sau de la o versiune la alta cu ceva upgrade-uri majore, nu > mai tin minte. > > Daca crezi ca degetele iti vor umbla pe butoane si dialoguri > aiurea fara sa consulte creierii dintre urechi poti sa deconectezi fizic > acele discuri din masina si sa le reconectezi dupa ce termini instalarea. > La fel de bine poti sa faci ce ti s-a mai recomandat, adica sa le > asignezi un mount point (romanizeaza asta!) fara a le formata, sau sa le > ignori urmind sa modifici manual fstab (la asta cum i se spune in > romana?). > > > P.S.: Trebuie sa mai intelegeti ca profesati (sau doar sinteti pasionati > sau interesati) de un domeniu caruia i s-au pus bazele intr-o alta tara > care are alta limba oficiala decit cea romana. > Inevitabil in aceste cazuri apar termeni care trebuiesc importati > in alte limbi pentru claritate, ca altfel ajungem sa vorbim despre > cocktete de atac aerian si sa ne trezim atacati nuclear de cine stie ce > panicat care a dat prin google translate un simplu text si a dedus ca vrem > sa-i atacam tara cu o ploaie de de biti, cockteti si lacuste slobozite > asupra meleaguril
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
Fiecare disc parte dintr-o matrice (sau arie, uvertura, cocktet sau cum vrei tu sa-l botezi aici) RAID (hopa! pentru RAID nu ai echivalentul purrromanesc? Baga si tu ceva, "atac aerian" de exemplu) are prin primele sectoare diverse informatii cu privire la array-ul (na!!) raid din care face parte. Daca la reinstalare nu repartitionezi acele discuri sau nu formatezi fortat partitiile membre atunci nu vei avea probleme. Minunile alea ezoterice de genul "silent data curruption" si alte misticisme de genul se intimpla in niste situatii specifice, de exemplu discuri varza sau greenFAIL exploatate ca si unele sanatoase la cap, sau ecranate necorespunzator pentru acel tip de disc si mediul in care sint exploatate, sau discuri care au ramas fara sectoare de relocare insa nu se uita nici mutu' cum urla ele acolo in sinea lor prin SMART. Poti incerca sa lasi telefonul mobil pe carcasa unui server zi de zi si dupa citeva saptamini/luni e posibil (dar nu neaparat, trebuie sa fie si carcasa aiurea, si discul, etc) sa vezi minuni pe discuri. E doar un exemplu. Alte probleme mai pot aparea cu discurile care sint foarte aproape de tunere TV, de sursele PC, samd. Dar nu apar din cauza RAID-ului, si nici nu e menirea implementarilor RAID sa le corecteze. Problemele cu matricile raid la distributii mai noi sau mai vechi au cam disparut undeva prin 2002-2003 cred, nu mai tin minte versiunea de kernel dar cred ca eram inca la 2.4.x (2.4.21?). La vremea respectiva trebuia refacut array-ul fortat, mentinindu-se aceiasi parametri (tip, chunk size, etc) si dupa refacere daca nu dadeai cu tirnacopul in discuri inainte aveai toate datele intacte. Cred ca tocmai se trecea la mdadm in perioada aia, sau de la o versiune la alta cu ceva upgrade-uri majore, nu mai tin minte. Daca crezi ca degetele iti vor umbla pe butoane si dialoguri aiurea fara sa consulte creierii dintre urechi poti sa deconectezi fizic acele discuri din masina si sa le reconectezi dupa ce termini instalarea. La fel de bine poti sa faci ce ti s-a mai recomandat, adica sa le asignezi un mount point (romanizeaza asta!) fara a le formata, sau sa le ignori urmind sa modifici manual fstab (la asta cum i se spune in romana?). P.S.: Trebuie sa mai intelegeti ca profesati (sau doar sinteti pasionati sau interesati) de un domeniu caruia i s-au pus bazele intr-o alta tara care are alta limba oficiala decit cea romana. Inevitabil in aceste cazuri apar termeni care trebuiesc importati in alte limbi pentru claritate, ca altfel ajungem sa vorbim despre cocktete de atac aerian si sa ne trezim atacati nuclear de cine stie ce panicat care a dat prin google translate un simplu text si a dedus ca vrem sa-i atacam tara cu o ploaie de de biti, cockteti si lacuste slobozite asupra meleagurilor sale natale sub forma de mana cereasca cu smecleti. -- I'm a genuine network and sys admin. I swear, I curse, I stick my dick into things in order to fix them. So don't ack like you're having a bad day with me around, 'cause I'll have fix to you and will not be able to fight it! ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
Quoting "Paul Lacatus (Personal)" : > > On 11.11.2013 14:58, Iulian Murgulet wrote: >> Quoting Petru Ratiu : >> >>> 2013/11/11 Paul Lacatus (Personal) >>> Am o arie de hard-uri intr-un Raid soft linux . Sunt numai date , nici una din zonele de lucru linux nu sunt pe aceste discuri . Vreau sa reinstalez linux-ul fara sa afectez in nici un fel continutul ariei . As prefera sa le demontez soft , sa le deconectez si sa instalez centos 6.4 de la zero pe masina care a fost cu FC12. Apoi sa le conectez si sa le remontez software. Credeti ca ar putea aparea probleme? Are cineva un step by step to do ? >>> Sarind peste bariera de limbaj (e de apreciat evitarea romglezei, dar >>> incearca sa fii totusi mai specific sa te intelegm si noi astia mai >>> formatati gresit), singura problema pe care o vad este sa nu le incurci la >>> instalare si sa le formatezi. Daca zici ca-s deconectate fizic pe perioada >>> instalarii, nu prea are ce sa nu mearga, driverul de raid software din >>> linux e backwards compatible cu formatele on-disk de la inceputurile >>> inceputurilor. >>> >> ... pot aparea probleme dupa. Daca ai ghinion(am patit de 2 ori)in 5 >> ani, si la un moment dat pe discul A(din matricea RAID) sectorul A1 >> care continut diferit de sectorul B1 de pe discul B(A1 si B1 ar trebui >> sa fie identice ca si continut), ghici ce se intampla ? Ce date >> crezi ca vei avea ? >> Pana afli raspunsul iti doresc un MD cu A1=B1 ;) >> >> >> > In primul rind raid-ul e 5 asa ca nu prea am continuturi identice intre > sectoare , si in al doilea rind cind dau demontarea ( umount ) driverul > nu face mai intii sincronizarea discurilor ? Nu la asta ma refeream. La MD(asa zis-ul RAID, ca e raid1 sau raid5) e de fapt FAKE RAID. Oricum md (fake)raid5 e mai rau decat (fake)raid1. Uita-te dupa "sielent coruption". Daca ai ghinion(probabilitatea e mai mare daca HDD-le) sunt de generatie mai noua si de capacitate mai mare), te poti trezi intr-o zi cu soare, ca ai date corupte. http://www.necam.com/Docs/?id=54157ff5-5de8-4966-a99d-341cf2cb27d3 http://www.zdnet.com/blog/storage/data-corruption-is-worse-than-you-know/191 "The experiments at CERN - high energy "shots" that create many terabytes of data in a few seconds - then require months of careful statistical analysis to find traces of rare and short-lived particles. Errors in the data could invalidate the results, so CERN scientists and engineers did a systematic analysis to find silent data corruption events. Statistics work best with large sample sizes. As you'll see CERN has very large sample sizes. The program The analysis looked at data corruption at 3 levels: Disk errors.The wrote a special 2 GB file to more than 3,000 nodes every 2 hours and read it back checking for errors for 5 weeks. They found 500 errors on 100 nodes. Single bit errors. 10% of disk errors. Sector (512 bytes) sized errors. 10% of disk errors. 64 KB regions. 80% of disk errors. This one turned out to be a bug in WD disk firmware interacting with 3Ware controller cards which CERN fixed by updating the firmware in 3,000 drives." ... deci daca tii la date trebuie sa-ti iei alte masuri. MD raid nu e cea mai buna varianta d.p.d.v. al protectiei datelor. Bafta mai departe cu mdraid, oricare ar fi el 1 sau 5. Cred ca o sa ai multa nevoie ... :) > ___ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug > 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 RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
On 11/11/2013 05:13 PM, Paul Lacatus (Personal) wrote: > On 11.11.2013 14:58, Iulian Murgulet wrote: >> Quoting Petru Ratiu : >> >>> 2013/11/11 Paul Lacatus (Personal) >>> Am o arie de hard-uri intr-un Raid soft linux . Sunt numai date , nici una din zonele de lucru linux nu sunt pe aceste discuri . Vreau sa reinstalez linux-ul fara sa afectez in nici un fel continutul ariei . As prefera sa le demontez soft , sa le deconectez si sa instalez centos 6.4 de la zero pe masina care a fost cu FC12. Apoi sa le conectez si sa le remontez software. Credeti ca ar putea aparea probleme? Are cineva un step by step to do ? >>> Sarind peste bariera de limbaj (e de apreciat evitarea romglezei, dar >>> incearca sa fii totusi mai specific sa te intelegm si noi astia mai >>> formatati gresit), singura problema pe care o vad este sa nu le incurci la >>> instalare si sa le formatezi. Daca zici ca-s deconectate fizic pe perioada >>> instalarii, nu prea are ce sa nu mearga, driverul de raid software din >>> linux e backwards compatible cu formatele on-disk de la inceputurile >>> inceputurilor. >>> >> ... pot aparea probleme dupa. Daca ai ghinion(am patit de 2 ori)in 5 >> ani, si la un moment dat pe discul A(din matricea RAID) sectorul A1 >> care continut diferit de sectorul B1 de pe discul B(A1 si B1 ar trebui >> sa fie identice ca si continut), ghici ce se intampla ? Ce date >> crezi ca vei avea ? >> Pana afli raspunsul iti doresc un MD cu A1=B1 ;) >> >> >> > In primul rind raid-ul e 5 asa ca nu prea am continuturi identice intre > sectoare , si in al doilea rind cind dau demontarea ( umount ) driverul > nu face mai intii sincronizarea discurilor ? ba da am facut sportul asta ( ma rog, chestii similare ) de tz ori. la mine situatia a fost in general " masina virtuala X are centos N si vreau sa fac update. asa ca instalez un Centos N+1 ( sau N+2) si montez in el raid-ul". nu am avut niciodata probleme iar in decursul anilor am tot trecut centos3/4 la C5/C6 si C5 la C6. singura situatie in care pot sa apara probleme este cea in care incerci sa accesezi raid-ul din o distributie mai veche decit cea in care fost creat. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
On 11.11.2013 14:58, Iulian Murgulet wrote: > Quoting Petru Ratiu : > >> 2013/11/11 Paul Lacatus (Personal) >> >>> Am o arie de hard-uri intr-un Raid soft linux . Sunt numai date , nici >>> una din zonele de lucru linux nu sunt pe aceste discuri . Vreau sa >>> reinstalez linux-ul fara sa afectez in nici un fel continutul ariei . As >>> prefera sa le demontez soft , sa le deconectez si sa instalez centos >>> 6.4 de la zero pe masina care a fost cu FC12. Apoi sa le conectez si >>> sa le remontez software. >>> >>> Credeti ca ar putea aparea probleme? Are cineva un step by step to do ? >>> >>> >> Sarind peste bariera de limbaj (e de apreciat evitarea romglezei, dar >> incearca sa fii totusi mai specific sa te intelegm si noi astia mai >> formatati gresit), singura problema pe care o vad este sa nu le incurci la >> instalare si sa le formatezi. Daca zici ca-s deconectate fizic pe perioada >> instalarii, nu prea are ce sa nu mearga, driverul de raid software din >> linux e backwards compatible cu formatele on-disk de la inceputurile >> inceputurilor. >> > ... pot aparea probleme dupa. Daca ai ghinion(am patit de 2 ori)in 5 > ani, si la un moment dat pe discul A(din matricea RAID) sectorul A1 > care continut diferit de sectorul B1 de pe discul B(A1 si B1 ar trebui > sa fie identice ca si continut), ghici ce se intampla ? Ce date > crezi ca vei avea ? > Pana afli raspunsul iti doresc un MD cu A1=B1 ;) > > > In primul rind raid-ul e 5 asa ca nu prea am continuturi identice intre sectoare , si in al doilea rind cind dau demontarea ( umount ) driverul nu face mai intii sincronizarea discurilor ? ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
Quoting Petru Ratiu : > 2013/11/11 Paul Lacatus (Personal) > >> Am o arie de hard-uri intr-un Raid soft linux . Sunt numai date , nici >> una din zonele de lucru linux nu sunt pe aceste discuri . Vreau sa >> reinstalez linux-ul fara sa afectez in nici un fel continutul ariei . As >> prefera sa le demontez soft , sa le deconectez si sa instalez centos >> 6.4 de la zero pe masina care a fost cu FC12. Apoi sa le conectez si >> sa le remontez software. >> >> Credeti ca ar putea aparea probleme? Are cineva un step by step to do ? >> >> > > Sarind peste bariera de limbaj (e de apreciat evitarea romglezei, dar > incearca sa fii totusi mai specific sa te intelegm si noi astia mai > formatati gresit), singura problema pe care o vad este sa nu le incurci la > instalare si sa le formatezi. Daca zici ca-s deconectate fizic pe perioada > instalarii, nu prea are ce sa nu mearga, driverul de raid software din > linux e backwards compatible cu formatele on-disk de la inceputurile > inceputurilor. > ... pot aparea probleme dupa. Daca ai ghinion(am patit de 2 ori)in 5 ani, si la un moment dat pe discul A(din matricea RAID) sectorul A1 care continut diferit de sectorul B1 de pe discul B(A1 si B1 ar trebui sa fie identice ca si continut), ghici ce se intampla ? Ce date crezi ca vei avea ? Pana afli raspunsul iti doresc un MD cu A1=B1 ;) > -- > P. > ___ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug > 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 RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
2013/11/11 Paul Lacatus (Personal) > Am o arie de hard-uri intr-un Raid soft linux . Sunt numai date , nici > una din zonele de lucru linux nu sunt pe aceste discuri . Vreau sa > reinstalez linux-ul fara sa afectez in nici un fel continutul ariei . As > prefera sa le demontez soft , sa le deconectez si sa instalez centos > 6.4 de la zero pe masina care a fost cu FC12. Apoi sa le conectez si > sa le remontez software. > > Credeti ca ar putea aparea probleme? Are cineva un step by step to do ? > > Sarind peste bariera de limbaj (e de apreciat evitarea romglezei, dar incearca sa fii totusi mai specific sa te intelegm si noi astia mai formatati gresit), singura problema pe care o vad este sa nu le incurci la instalare si sa le formatezi. Daca zici ca-s deconectate fizic pe perioada instalarii, nu prea are ce sa nu mearga, driverul de raid software din linux e backwards compatible cu formatele on-disk de la inceputurile inceputurilor. -- P. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
On 11/11/2013 01:55 PM, Paul Lacatus (Personal) wrote: > Am o arie de hard-uri intr-un Raid soft linux . Sunt numai date , nici > una din zonele de lucru linux nu sunt pe aceste discuri . Vreau sa > reinstalez linux-ul fara sa afectez in nici un fel continutul ariei . As > prefera sa le demontez soft , sa le deconectez si sa instalez centos > 6.4 de la zero pe masina care a fost cu FC12. Apoi sa le conectez si > sa le remontez software. > > Credeti ca ar putea aparea probleme? Are cineva un step by step to do ? merge fara nici o problema exact cum ai descris. poti sa le si lasi conectate pe parcursul instalarii si sa ii si zici via disk druid unde sa le monteze, doar sa ai grija sa nu le formatezi. sau, ca sa fii sigur ca nu gresesti, lasa-le neatinse ( ignora-le ) pe parcusul instalarii si adauga-le manual dupa ce booteaza ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
