On 08/10/2013 11:51 PM, Alex 'CAVE' Cernat wrote: > interesant benchmarkul, nu inteleg de ce a iesit asa de prost zfs-ul cand > la prima vedere pare sa se descurce destul de bine (dar mai am destule date > de analizat pana la a trage o concluzie) din cite am auzit ZFS-ul merge bine pe multe discuri si imperios necesar sa ai device separat de ZIL (ssd sau pcie ssd) zfs on linux nu ai incercat? e zfs nativ http://zfsonlinux.org/ si am auzit lucruri bune despre el ...
> oricum principalul criteriu pentru mine ar fi overheadul la cp -al (cu cat > e mai mic cu atat se pot pastra mai multe snapshot-uri), urmat de > overheadul la tree-ul de rsync-uit (aka spatiul ocupat de structura de > directoare) si timpii de accesare binenteles (daca sunt nesimtit de mari, > cum vad ca patesc acum cu btrfs-ul ... se exclude automat fs-ul din lista) ca si modalitate de backup vezi http://www.amanda.org/ pare foarte complex ca optiuni .. din FAQ-ul lor vad o chestie interesanta: In the classic backup scheme you said: "I want to have incremental backups from Mo-Th and a full backup on Fr." Using Amanda you say: "I want to have at least one full backup in 5 days." Nu l-am incercat intru-cit pt mine rsync merge minunat (nu am mai mult de citiva gb de tranfer) si cu "Ciphers arcfour256" in .ssh/config am 70+ MiB/s HTH, Adrian > > > On Sat, Aug 10, 2013 at 11:30 PM, Adrian Sevcenco > <[email protected]>wrote: > >> On 08/10/2013 10:04 PM, Alex 'CAVE' Cernat wrote: >>> 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 >> Poate te ajuta testele de aici: >> http://www.phoronix.com/scan.php?page=article&item=linux_310_10fs&num=1 >> Caveat: testele sunt facute pe ssd .. pe un hdd e posibil lucrurile sa >> fie mult diferite... >> Nu am inteles ce inseamna "performanta de backup".. Pentru latenta de >> scriere a exturilor ai: >> ext3: >> commit=nrsec >> Sync all data and metadata every nrsec seconds. The default value is 5 >> seconds. Zero means default. >> >> ext4: >> in plus fata de ext3: >> journal_async_commit >> Commit block can be written to disk without waiting for descriptor >> blocks. If enabled older kernels cannot mount the device. This will >> enable 'journal_checksum' internally. >> >> in functie de mediul de stocare mai ai : >> nodelalloc >> Disable delayed allocation. Blocks are allocated when data is copied >> from user to page cache. >> >> min_batch_time=usec >> This parameter sets the commit time (as described above) to be at least >> min_batch_time. It defaults to zero microseconds. Increasing this >> parameter may improve the throughput of multi-threaded, synchronous >> workloads on very fast disks, at the cost of increasing latency. >> >> journal_ioprio=prio >> The I/O priority (from 0 to 7, where 0 is the highest priorty) which >> should be used for I/O operations submitted by kjournald2 during a >> commit operation. This defaults to 3, which is a slightly higher >> priority than the default I/O priority. >> >> HTH, >> Adrian >> >> >> _______________________________________________ >> RLUG mailing list >> [email protected] >> http://lists.lug.ro/mailman/listinfo/rlug >> >> > _______________________________________________ > RLUG mailing list > [email protected] > http://lists.lug.ro/mailman/listinfo/rlug >
_______________________________________________ RLUG mailing list [email protected] http://lists.lug.ro/mailman/listinfo/rlug
