Quoting Alex 'CAVE' Cernat <[email protected]>: > salutare > > pentru ca mi s-a acrit de mult de tar-uri, care oricum nu prea sunt bune de > nimic atunci cand ajung la o dimensiune considerabila (dar putina lume > intelege din pacate), rsync-ul incremental (aka rsync && cp -al) e net > superior din multe puncte de vedere (desi cu mai noile sisteme se pot > folosi facilitatile de snapshot, care fac transparent acelasi lucru cu > rsync-ul incremental; rsync-ul are totusi un avantaj, si anume 100% > control, mai ales ca ai mai multe surse de backup-at) > > testez de vreo cateva zile tot felul de filesysteme si optiuni, sa vad care > s-ar prinde cel mai bine, momentan o singura concluzie clara: jfs-ul o suge > rau de tot in conditiile date, atat ca overhead de spatiu ocupat, cat si ca > timpi > > ce mi se pare foarte ciudat este ca atat btrfs-ul, cat si zfs-ul (varianta > fuse) par sa faca scrierile pe disc cu mare intarziere (si da, dupa fiecare > nebunie de comanda dau un time sync, care teoretic ar trebui sa scrie tot > cache-ul pe disc, dar se pare ca nu ajunge nici macar in cache decat mai > tarziu, asa ca, prima intrebare: > 1) exista vreo modalitate la btrfs si zfs sa le fortez sa scrie totul pe > disc (in afara de un unmount/mount, care pare totusi cam fascist ?)
ZFS: echo 3 > /proc/sys/vm/drop_caches - ZFS are multi parametri car se pot tuna/regla; - ZFS tocmai asta stie sa faca, garanteaza ca datele sunt scrise pe discuri(presupunand ca nu am probleme de alta natura), foloseste tranzactii si scrie datele in mod atomic(de aia nu e nevoie de fsck); - datele sunt scrise intaii in RAM si apoi sunt varsate pe disk(implicit 5 sec, prin parametrul tgx); - scrierile merg mai greu, pt. ca la orice bloc scris pe disk, el scrie si un check-sum al acelui bloc(util pt. ca datele citite cu succes sunt asa cum au fost ele scrise prin compararea check-sum-lor de la citire cu cele stocate pe disk la scriere) - si pt. un backup asta este esential dupa mine; - pot sa fie si alte probleme de performanta la scrieri daca de exemplu, disk-ul in cauza foloseste bloc-ri de 4k, si partitia alocata pt. zfs nu este aliniata la 4k, sau discul minte in legatura cu marime blocului(vezi parametrul ashift=9 sau 12); - implicit in cache-ul de ZFS se tin date si meta-date, si in functie de pattern-ul de access(si de RAM-ul de pe masina), se poate opta de exemplu sa tii numai meta-datele in cache(util daca operezi pe f. multe fisiere) sau sa limitezi cat ram sa ocupi pt. meta-date... - un simplu rasync nu cred ca e concludent, ca si test, incearca de exemplu sa rulezi succesiv mai multe rsync-ri(cu sursa de date modificata), e posibil sa ai surprize. - daca datele care le pui in ZFS sunt comprimabile, se poate utiliza compresia(recomandat algoritm-ul LZO) si asta automat conduce la cresterea vitezei(comprimarea/decomprimarea e mai rapida decat in general decat citirea/scrierea de date necomprimate direct pe disk); - din experenta mea, cu rsync si zfs(tunat/personalizat), pe acelasi hardware, nu am observat diferente notabile intre ZFS si ext4 de exemplu(comparatie facuta de mine pe cel putin 2 masini, cu raid1-md si ext4 respectiv zfs-mirror si acelasi set de date transferat prin rsync - seturi-le de date au fost de 20 GB respectiv 150 GB continand mail-ri, dbf-ri, pdf-ri si doc/xls). - oricum cele mai bune performante se obtin daca aloci ZFS-ui un intreg HDD si nu o partitie si ai grija sa ai 20% spatiu liber; > > la prima vedere castigatorii la less overhead pe disk (atunci cand e vorba > de caruta de subdirectoare link-uite) ar fi reiserfs, xfs si ext4 cu block > size de 1k (by default ext4 cu 4k iese din grafice rau la capitolul > overhead de spatiu) > din pacate reiserfs-ul e cam pe linie moarta, ca altfel a fost cu mici > exceptii (in sensul de batai de cap, nu de pierdere de date) excelent la > timpul lui > > stiu ca nu e vineri, dar totusi o flama constructiva n-ar strica, legat de > performantele fs-urilor strict pentru spatiu de backup > deocamdata il mai las sa ruleze niste teste, o sa vad pe luni rezultatele > > Alex > > ps: ext4, xfs, reiserfs, jfs (bleah), btrfs (prea bun, dar prea > experimental), zfs ... am uitat ceva ? (nu ma luati cu ntfs, ca licitez cu > un fat16) > _______________________________________________ > RLUG mailing list > [email protected] > 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 [email protected] http://lists.lug.ro/mailman/listinfo/rlug
