Re: [rlug] Sa imi cumpar alte HDD-uri ?
On Mon, 10 Mar 2014, Paul Lacatus (Personal) wrote: > Azi am rulat un test scurt de citeva ori . Rezultatul este mai jos . > Discurile nu au sectoare realocate inca . Ce sa fac sa le schimb pe > cele doua ? Nu inca. E vorba de un singur sector, altele realocate nu mai sint, si chair daca ar fi ar trebui sa incepi sa te panichezi pe la 15-20.. > >> [root@datavault ~]# smartctl -a /dev/sde >> smartctl 5.43 2012-06-30 r3573 >> [x86_64-linux-2.6.32-431.5.1.el6.x86_64] (local build) >> Copyright (C) 2002-12 by Bruce Allen, http://smartmontools.sourceforge.net >> >> === START OF INFORMATION SECTION === >> Model Family: SAMSUNG SpinPoint F3 Datavault... samsung... valeleuu...! CPU-ul e un amd si chipsetul nvidia? -- 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] Din nou despre ZFS (was Re: Sa imi cumpar alte HDD-uri ?)
Quoting Adi Pircalabu : > Pe mine m-ar interesa integrarea ZFS intr-un cluster activ/activ cu > pacemaker si corosync. Nu vad de ce nu ar merge. Eu am ceva similar cu 4 noduri(activ/activ, datele pe ZFS) dar e cu ucarp/haproxy si glusterfs(raid1 pe 4 cai si quorum). Peste astea, am servicii de cluster(load-balancing/fail-over): proxy-http/http(s)/web-mail/postfix/samba(numai fail-over). Nu am lucrat cu pacemaker, deci mai mult nu stiu sa zic > > 2014-03-13 0:10 GMT+11:00 Iulian Murgulet : >> Quoting Alex 'CAVE' Cernat : >> >>> On 3/12/2014 1:05 PM, Iulian Murgulet wrote: Subscriu si eu la asta, si adaug tot offtopic, chiar daca poate unii o sa ma "ciufuleasca" din nou, dar o sa pomenesc din nou despre ZFS(facand abstratie de peisajul in care opereaza acel RAID5). Evident, daca doresti detalii pentru cazul tau concret, te pot ajuta cu mai multe(mai ales ca am reusit sa convertesc un alt co-listas la ZFS). >>> >>> sa zica si 'convertitul' vreo 2 vorbe, avantaje si 'dezavantaje' la zfs >>> >>> sa incepem cu dezavantajele: >>> - nu e in kernel (mama lor de licente); insa folosind zol se compileaza >>> relativ usor cu dkms (cel putin pe debian); nu prea imi place sa stiu >>> compilator pe servere, dar spre exemplu si la un banal varnish e aceeasi >>> cerinta; ca sa fii mai catolic decat papa cred ca merge sa ai o masina >>> virtuala ceva in care sa compilezi si sa transferi modulele pe serverul >>> de productie >>> - consum cam maricel de memorie (pleci de la 3-4 giga doar pentru el) >>> - cam multe procese zfs-related pe masina (se poate tuna, momentan mi-a >>> fost lene) >>> - la ce am avut eu nevoie (backup) performantele au fost asemanatoare cu >>> celelalte fs-uri (poate un pic mai lent, dar nu vizibil) >>> - desi se poate pune ca root filesystem, eu unul cel putin nu l-as >>> folosi, parca e prea rocket science si prea multe chestii care ar putea >>> duce la belele (parerea mea) >>> >>> si acum sa vina avantajele (multe s-au zis, le reiau doar fugitiv, si >>> probabil de multe o sa uit) >>> - posibilitate de raid; rebuildul doar la datele existente >>> - verificare a datelor (realtime si on/offline - nu stiu unde sa trec >>> scrub-ul, ca practic se face online cu partitia montata si functionala) >>> - gestionare flexibila a spatiului de pe disc, se foloseste la gramada >>> (nu mai stai sa te mai gandesti din start ca am nevoie de atat pentru >>> proiectul x); ai posibilitatea de garantari si rezervari, in caz ca vrei >>> sa lasi spatiu prealocat pentru un mount, sau vrei sa fixezi o limita >>> superioara pentru altul >>> - compresie onthefly, separat pentru fiecare mount in parte >>> - snapshot-uri fara numar fara numar, posibilitate de revert si clonare >>> (am testat niste scenarii si am fost multumit) >>> >>> enormul dezavantaj este partea de de-duplicare a datelor, care este >>> implementat cam cu fundul, si care pentru a-l folosi e nevoie de >>> cantitati uriase de memorie (cca 5 GB memorie la 1 TB date alocate); si >>> degeaba pui ssd, ca tot nu o scoti la capat (poate pe viitor vor gandi >>> sa ii faca cumva cache-ul separat pe un ssd ceva, sau o implementare >>> non-realtime, cum e la geamuri); in prezent asa cum e, in marea-marea >>> majoritate a cazurilor nu este fezabil, deci e ca si cum nu ar fi >>> >>> in concluzie, daca pe un server gen web parca nu l-as pune (desi >>> avantajele ar fi multe), in schimb pentru un storage merge brici, deci >>> il pot recomanda cu incredere >>> >>> Alex >>> >> >> Mersi Alex, prezentarea este foarte obiectiva(si cu bune si cu rele). >> >> Am o singura observatie la ce a scris Alex, intradevar partea de deduplicare >> e cam super-nashpa in termeni de performanta, dar totusi da rezultate >> acceptatbile intr-un caz particular: de-deuplicare pe volume relativ >> mici >> de date(2-300 GB) plasate pe SSD-ri. >> >> Si mai mentionez 2 avantaje/posibilitati: >> 1. Posibilitatea de a modifica varianta de redundanta curenta intr-o >> varianta superioara, adaugand HDD-ri suplimentare: am zpool >> mirror(adica raid1) >> peste 2 HDD-ri, si vreau sa ajung la raidz2, adaugand inca 2 HDD-ri. Este >> perfect posibil(mie mi-a resuit in mai multe ocazii, evident aveam >> si backup) >> 2. zfs send/receive: am 2 masini diferite zfs-capabile, pot crea un >> stream de >> pe masina 1 catre masina 2 printr-un pipe de transport gen ssh >> - in felul asta pot face backup de pe 1 pe 2 foarte eficient(incremental de >> exemplu, si pt. asta zfs-ul nu trebuie sa faca ceva gen rsync, adica >> sa calculeze pe moment ce trenuie transmis, zfs-ul are deja stocata >> informatia privind blocurile afectate) >> >> >> >> >> >> >> >>> ___ >>> RLUG mailing list >>> RLUG@lists.lug.ro >>> http://lists.lug.ro/mailman/listinfo/rlug >>> >> >> >> >> >> This message was sent using IMP, the Internet Messaging Program. >> >> >>
[rlug] Din nou despre ZFS (was Re: Sa imi cumpar alte HDD-uri ?)
Pe mine m-ar interesa integrarea ZFS intr-un cluster activ/activ cu pacemaker si corosync. 2014-03-13 0:10 GMT+11:00 Iulian Murgulet : > Quoting Alex 'CAVE' Cernat : > >> On 3/12/2014 1:05 PM, Iulian Murgulet wrote: >>> Subscriu si eu la asta, si adaug tot offtopic, chiar daca poate >>> unii o sa ma "ciufuleasca" din nou, dar o sa pomenesc din nou despre >>> ZFS(facand abstratie de peisajul in care opereaza acel RAID5). >>> Evident, daca doresti detalii pentru cazul tau concret, te pot ajuta >>> cu mai multe(mai ales ca am reusit sa convertesc un alt co-listas la >>> ZFS). >> >> sa zica si 'convertitul' vreo 2 vorbe, avantaje si 'dezavantaje' la zfs >> >> sa incepem cu dezavantajele: >> - nu e in kernel (mama lor de licente); insa folosind zol se compileaza >> relativ usor cu dkms (cel putin pe debian); nu prea imi place sa stiu >> compilator pe servere, dar spre exemplu si la un banal varnish e aceeasi >> cerinta; ca sa fii mai catolic decat papa cred ca merge sa ai o masina >> virtuala ceva in care sa compilezi si sa transferi modulele pe serverul >> de productie >> - consum cam maricel de memorie (pleci de la 3-4 giga doar pentru el) >> - cam multe procese zfs-related pe masina (se poate tuna, momentan mi-a >> fost lene) >> - la ce am avut eu nevoie (backup) performantele au fost asemanatoare cu >> celelalte fs-uri (poate un pic mai lent, dar nu vizibil) >> - desi se poate pune ca root filesystem, eu unul cel putin nu l-as >> folosi, parca e prea rocket science si prea multe chestii care ar putea >> duce la belele (parerea mea) >> >> si acum sa vina avantajele (multe s-au zis, le reiau doar fugitiv, si >> probabil de multe o sa uit) >> - posibilitate de raid; rebuildul doar la datele existente >> - verificare a datelor (realtime si on/offline - nu stiu unde sa trec >> scrub-ul, ca practic se face online cu partitia montata si functionala) >> - gestionare flexibila a spatiului de pe disc, se foloseste la gramada >> (nu mai stai sa te mai gandesti din start ca am nevoie de atat pentru >> proiectul x); ai posibilitatea de garantari si rezervari, in caz ca vrei >> sa lasi spatiu prealocat pentru un mount, sau vrei sa fixezi o limita >> superioara pentru altul >> - compresie onthefly, separat pentru fiecare mount in parte >> - snapshot-uri fara numar fara numar, posibilitate de revert si clonare >> (am testat niste scenarii si am fost multumit) >> >> enormul dezavantaj este partea de de-duplicare a datelor, care este >> implementat cam cu fundul, si care pentru a-l folosi e nevoie de >> cantitati uriase de memorie (cca 5 GB memorie la 1 TB date alocate); si >> degeaba pui ssd, ca tot nu o scoti la capat (poate pe viitor vor gandi >> sa ii faca cumva cache-ul separat pe un ssd ceva, sau o implementare >> non-realtime, cum e la geamuri); in prezent asa cum e, in marea-marea >> majoritate a cazurilor nu este fezabil, deci e ca si cum nu ar fi >> >> in concluzie, daca pe un server gen web parca nu l-as pune (desi >> avantajele ar fi multe), in schimb pentru un storage merge brici, deci >> il pot recomanda cu incredere >> >> Alex >> > > Mersi Alex, prezentarea este foarte obiectiva(si cu bune si cu rele). > > Am o singura observatie la ce a scris Alex, intradevar partea de deduplicare > e cam super-nashpa in termeni de performanta, dar totusi da rezultate > acceptatbile intr-un caz particular: de-deuplicare pe volume relativ > mici > de date(2-300 GB) plasate pe SSD-ri. > > Si mai mentionez 2 avantaje/posibilitati: > 1. Posibilitatea de a modifica varianta de redundanta curenta intr-o > varianta superioara, adaugand HDD-ri suplimentare: am zpool > mirror(adica raid1) > peste 2 HDD-ri, si vreau sa ajung la raidz2, adaugand inca 2 HDD-ri. Este > perfect posibil(mie mi-a resuit in mai multe ocazii, evident aveam si backup) > 2. zfs send/receive: am 2 masini diferite zfs-capabile, pot crea un stream de > pe masina 1 catre masina 2 printr-un pipe de transport gen ssh > - in felul asta pot face backup de pe 1 pe 2 foarte eficient(incremental de > exemplu, si pt. asta zfs-ul nu trebuie sa faca ceva gen rsync, adica > sa calculeze pe moment ce trenuie transmis, zfs-ul are deja stocata > informatia privind blocurile afectate) > > > > > > > >> ___ >> 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 > > ===
Re: [rlug] Sa imi cumpar alte HDD-uri ?
Quoting Alex 'CAVE' Cernat : > On 3/12/2014 1:05 PM, Iulian Murgulet wrote: >> Subscriu si eu la asta, si adaug tot offtopic, chiar daca poate >> unii o sa ma "ciufuleasca" din nou, dar o sa pomenesc din nou despre >> ZFS(facand abstratie de peisajul in care opereaza acel RAID5). >> Evident, daca doresti detalii pentru cazul tau concret, te pot ajuta >> cu mai multe(mai ales ca am reusit sa convertesc un alt co-listas la >> ZFS). > > sa zica si 'convertitul' vreo 2 vorbe, avantaje si 'dezavantaje' la zfs > > sa incepem cu dezavantajele: > - nu e in kernel (mama lor de licente); insa folosind zol se compileaza > relativ usor cu dkms (cel putin pe debian); nu prea imi place sa stiu > compilator pe servere, dar spre exemplu si la un banal varnish e aceeasi > cerinta; ca sa fii mai catolic decat papa cred ca merge sa ai o masina > virtuala ceva in care sa compilezi si sa transferi modulele pe serverul > de productie > - consum cam maricel de memorie (pleci de la 3-4 giga doar pentru el) > - cam multe procese zfs-related pe masina (se poate tuna, momentan mi-a > fost lene) > - la ce am avut eu nevoie (backup) performantele au fost asemanatoare cu > celelalte fs-uri (poate un pic mai lent, dar nu vizibil) > - desi se poate pune ca root filesystem, eu unul cel putin nu l-as > folosi, parca e prea rocket science si prea multe chestii care ar putea > duce la belele (parerea mea) > > si acum sa vina avantajele (multe s-au zis, le reiau doar fugitiv, si > probabil de multe o sa uit) > - posibilitate de raid; rebuildul doar la datele existente > - verificare a datelor (realtime si on/offline - nu stiu unde sa trec > scrub-ul, ca practic se face online cu partitia montata si functionala) > - gestionare flexibila a spatiului de pe disc, se foloseste la gramada > (nu mai stai sa te mai gandesti din start ca am nevoie de atat pentru > proiectul x); ai posibilitatea de garantari si rezervari, in caz ca vrei > sa lasi spatiu prealocat pentru un mount, sau vrei sa fixezi o limita > superioara pentru altul > - compresie onthefly, separat pentru fiecare mount in parte > - snapshot-uri fara numar fara numar, posibilitate de revert si clonare > (am testat niste scenarii si am fost multumit) > > enormul dezavantaj este partea de de-duplicare a datelor, care este > implementat cam cu fundul, si care pentru a-l folosi e nevoie de > cantitati uriase de memorie (cca 5 GB memorie la 1 TB date alocate); si > degeaba pui ssd, ca tot nu o scoti la capat (poate pe viitor vor gandi > sa ii faca cumva cache-ul separat pe un ssd ceva, sau o implementare > non-realtime, cum e la geamuri); in prezent asa cum e, in marea-marea > majoritate a cazurilor nu este fezabil, deci e ca si cum nu ar fi > > in concluzie, daca pe un server gen web parca nu l-as pune (desi > avantajele ar fi multe), in schimb pentru un storage merge brici, deci > il pot recomanda cu incredere > > Alex > Mersi Alex, prezentarea este foarte obiectiva(si cu bune si cu rele). Am o singura observatie la ce a scris Alex, intradevar partea de deduplicare e cam super-nashpa in termeni de performanta, dar totusi da rezultate acceptatbile intr-un caz particular: de-deuplicare pe volume relativ mici de date(2-300 GB) plasate pe SSD-ri. Si mai mentionez 2 avantaje/posibilitati: 1. Posibilitatea de a modifica varianta de redundanta curenta intr-o varianta superioara, adaugand HDD-ri suplimentare: am zpool mirror(adica raid1) peste 2 HDD-ri, si vreau sa ajung la raidz2, adaugand inca 2 HDD-ri. Este perfect posibil(mie mi-a resuit in mai multe ocazii, evident aveam si backup) 2. zfs send/receive: am 2 masini diferite zfs-capabile, pot crea un stream de pe masina 1 catre masina 2 printr-un pipe de transport gen ssh - in felul asta pot face backup de pe 1 pe 2 foarte eficient(incremental de exemplu, si pt. asta zfs-ul nu trebuie sa faca ceva gen rsync, adica sa calculeze pe moment ce trenuie transmis, zfs-ul are deja stocata informatia privind blocurile afectate) > ___ > 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] Sa imi cumpar alte HDD-uri ?
On 3/12/2014 1:05 PM, Iulian Murgulet wrote: > Subscriu si eu la asta, si adaug tot offtopic, chiar daca poate > unii o sa ma "ciufuleasca" din nou, dar o sa pomenesc din nou despre > ZFS(facand abstratie de peisajul in care opereaza acel RAID5). > Evident, daca doresti detalii pentru cazul tau concret, te pot ajuta > cu mai multe(mai ales ca am reusit sa convertesc un alt co-listas la > ZFS). sa zica si 'convertitul' vreo 2 vorbe, avantaje si 'dezavantaje' la zfs sa incepem cu dezavantajele: - nu e in kernel (mama lor de licente); insa folosind zol se compileaza relativ usor cu dkms (cel putin pe debian); nu prea imi place sa stiu compilator pe servere, dar spre exemplu si la un banal varnish e aceeasi cerinta; ca sa fii mai catolic decat papa cred ca merge sa ai o masina virtuala ceva in care sa compilezi si sa transferi modulele pe serverul de productie - consum cam maricel de memorie (pleci de la 3-4 giga doar pentru el) - cam multe procese zfs-related pe masina (se poate tuna, momentan mi-a fost lene) - la ce am avut eu nevoie (backup) performantele au fost asemanatoare cu celelalte fs-uri (poate un pic mai lent, dar nu vizibil) - desi se poate pune ca root filesystem, eu unul cel putin nu l-as folosi, parca e prea rocket science si prea multe chestii care ar putea duce la belele (parerea mea) si acum sa vina avantajele (multe s-au zis, le reiau doar fugitiv, si probabil de multe o sa uit) - posibilitate de raid; rebuildul doar la datele existente - verificare a datelor (realtime si on/offline - nu stiu unde sa trec scrub-ul, ca practic se face online cu partitia montata si functionala) - gestionare flexibila a spatiului de pe disc, se foloseste la gramada (nu mai stai sa te mai gandesti din start ca am nevoie de atat pentru proiectul x); ai posibilitatea de garantari si rezervari, in caz ca vrei sa lasi spatiu prealocat pentru un mount, sau vrei sa fixezi o limita superioara pentru altul - compresie onthefly, separat pentru fiecare mount in parte - snapshot-uri fara numar fara numar, posibilitate de revert si clonare (am testat niste scenarii si am fost multumit) enormul dezavantaj este partea de de-duplicare a datelor, care este implementat cam cu fundul, si care pentru a-l folosi e nevoie de cantitati uriase de memorie (cca 5 GB memorie la 1 TB date alocate); si degeaba pui ssd, ca tot nu o scoti la capat (poate pe viitor vor gandi sa ii faca cumva cache-ul separat pe un ssd ceva, sau o implementare non-realtime, cum e la geamuri); in prezent asa cum e, in marea-marea majoritate a cazurilor nu este fezabil, deci e ca si cum nu ar fi in concluzie, daca pe un server gen web parca nu l-as pune (desi avantajele ar fi multe), in schimb pentru un storage merge brici, deci il pot recomanda cu incredere Alex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Sa imi cumpar alte HDD-uri ?
Votez si eu tot ZFS si fa backup la matrice pe un alt mediu e tern si folisrste rsync sa actualizezi datele. Cand pica matricea sa ai de unde lua datele. Nu are rost ptr un sector sa te hazardezi. Numai de bine. În data de 12.03.2014 13:05, "Iulian Murgulet" a scris: > Quoting Adrian Sevcenco : > > > On 03/10/2014 02:24 PM, Paul Lacatus (Personal) wrote: > >> Ieri la pornirea unui sistem am primit doua e-mail-uri de la Smartd ca > >> a avut o eroare de citire pe cite un disc . Discurile sunt parti a unei > >> matrici raid 5 cu 4 discuri . > > relativ offtopic : IMHO nu e sanatos sa folosesti raid 5 cind totul se > > poate duce de ripa la un hdd cazut + o eroare de citire tranzienta. > >Subscriu si eu la asta, si adaug tot offtopic, chiar daca poate > unii o sa ma "ciufuleasca" din nou, dar o sa pomenesc din nou despre > ZFS(facand abstratie de peisajul in care opereaza acel RAID5). > Evident, daca doresti detalii pentru cazul tau concret, te pot ajuta > cu mai multe(mai ales ca am reusit sa convertesc un alt co-listas la > ZFS). > >In loc sa ai acest RAID5(habar nu am daca e md-raid sau hardware), te > poti > gandi la la ZFS, si pe cele 4 HDD-ri sa pui un ZFS de tip raidz1 sau > chiar raidz2(cu simpla=z1 sau dubla-z2 informatie de paritate). Deci > la raidz1 poti sa pierzi un disk si ai datele OK, la raidz2 poti > pierde 2 discuri, iar la raidz3 poti suptorta 3 discuri picate. Daca > ai fi avut asa > ceva era nesemnificativ daca aveai erori pe zona/zonele acoperite de > ZFS(atata timp cat exista suficienta informatie de paritate). Mai mult > chiar, ai fi putut determina relativ usor daca sunt si alte sectoare > care au probleme, iar ZFS-ul le rezolva on-the-fly(in cazul in care > exista suficienta redundanta de paritate) la citirea acelor sectoare > cu probleme, sau prin rularea unuei comenzi(zpool scrub) care > realizeaza verificare intregului pool cu date, si daca gaseste ceva > probleme te anunta frumos(a gasit X erori si a reparat eventual Y din > ele, unde Y poate sa fie egal cu X daca exista suficienta informatie > de paritate). > > Raidz 1/2/3 este de fapt echivalent cun raid6 clasic. > >Mai ai si avantajul, ca ceea ce se poate citi fara erori din pool, este > identic cu ce a fost scris in pool(se scrie un checksum la orice block > scris in pool, si se verifica acest checksum la orice citire). > > > am frecvente (2-3 la citeva luni) rebuilduri la arrayuri raid6 la care > > am avut 2 discuri cu read error in acelasi timp .. (arrayuri de pina la > > 15 discuri) > > > >Si eu am trecut cu raidz2(4 discuri) in regim de productie 1 HDD > picat(model enterprise), dar am stat linistit(pentru ca am fost sigur > ca probabilitatea sa mai pice inca 2 discuri era f. mica), dupa 3 zile > am pus alt disk in loc, sa re-sincronizat raid-ul(aici e alt avantaj, > ca se face sincronizarea DOAR pe partea cu date, nu pe tot HDD-ul sau > pe toata partitia). Am avut/am si sectoare care sunt raportate cu read > error(pe alte HDD-ri prinse tot in ZFS), dar in situatia in care sunt > depistate(la citire date sau la zpool scrub), ele sunt rezolvate de > ZFS, si asta nu conduce la excluderea vre'unui disk din mirror/raidzX, > si apoi la re-build de matrice(alt avantaj). > >Asta nu inseamna ca nu sunt si dezavantaje dar de multe ori > acestea pot fi minimizate. > > > > > > > > Adrian > > > > > > > > > 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 > ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Sa imi cumpar alte HDD-uri ?
Quoting Adrian Sevcenco : > On 03/10/2014 02:24 PM, Paul Lacatus (Personal) wrote: >> Ieri la pornirea unui sistem am primit doua e-mail-uri de la Smartd ca >> a avut o eroare de citire pe cite un disc . Discurile sunt parti a unei >> matrici raid 5 cu 4 discuri . > relativ offtopic : IMHO nu e sanatos sa folosesti raid 5 cind totul se > poate duce de ripa la un hdd cazut + o eroare de citire tranzienta. Subscriu si eu la asta, si adaug tot offtopic, chiar daca poate unii o sa ma "ciufuleasca" din nou, dar o sa pomenesc din nou despre ZFS(facand abstratie de peisajul in care opereaza acel RAID5). Evident, daca doresti detalii pentru cazul tau concret, te pot ajuta cu mai multe(mai ales ca am reusit sa convertesc un alt co-listas la ZFS). In loc sa ai acest RAID5(habar nu am daca e md-raid sau hardware), te poti gandi la la ZFS, si pe cele 4 HDD-ri sa pui un ZFS de tip raidz1 sau chiar raidz2(cu simpla=z1 sau dubla-z2 informatie de paritate). Deci la raidz1 poti sa pierzi un disk si ai datele OK, la raidz2 poti pierde 2 discuri, iar la raidz3 poti suptorta 3 discuri picate. Daca ai fi avut asa ceva era nesemnificativ daca aveai erori pe zona/zonele acoperite de ZFS(atata timp cat exista suficienta informatie de paritate). Mai mult chiar, ai fi putut determina relativ usor daca sunt si alte sectoare care au probleme, iar ZFS-ul le rezolva on-the-fly(in cazul in care exista suficienta redundanta de paritate) la citirea acelor sectoare cu probleme, sau prin rularea unuei comenzi(zpool scrub) care realizeaza verificare intregului pool cu date, si daca gaseste ceva probleme te anunta frumos(a gasit X erori si a reparat eventual Y din ele, unde Y poate sa fie egal cu X daca exista suficienta informatie de paritate). Raidz 1/2/3 este de fapt echivalent cun raid6 clasic. Mai ai si avantajul, ca ceea ce se poate citi fara erori din pool, este identic cu ce a fost scris in pool(se scrie un checksum la orice block scris in pool, si se verifica acest checksum la orice citire). > am frecvente (2-3 la citeva luni) rebuilduri la arrayuri raid6 la care > am avut 2 discuri cu read error in acelasi timp .. (arrayuri de pina la > 15 discuri) > Si eu am trecut cu raidz2(4 discuri) in regim de productie 1 HDD picat(model enterprise), dar am stat linistit(pentru ca am fost sigur ca probabilitatea sa mai pice inca 2 discuri era f. mica), dupa 3 zile am pus alt disk in loc, sa re-sincronizat raid-ul(aici e alt avantaj, ca se face sincronizarea DOAR pe partea cu date, nu pe tot HDD-ul sau pe toata partitia). Am avut/am si sectoare care sunt raportate cu read error(pe alte HDD-ri prinse tot in ZFS), dar in situatia in care sunt depistate(la citire date sau la zpool scrub), ele sunt rezolvate de ZFS, si asta nu conduce la excluderea vre'unui disk din mirror/raidzX, si apoi la re-build de matrice(alt avantaj). Asta nu inseamna ca nu sunt si dezavantaje dar de multe ori acestea pot fi minimizate. > Adrian > > 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
