Le 4 août 2013 à 17:25, K S Braunsdorf a écrit : > In message <b9cf2765-0bb7-4b0f-b758-1d5cf0219...@gmail.com>, AZ 9901 writes: >> Due to --link-dest, I have a huge read activity at the beginning of each >> backup, and huge hard links creation activity. >> I also plan to have several backups at the same time, coming from dozens >> of servers. > > Then the network will be the bottle-neck. I would stagger the backups > with some active management (not just stagger the start times). > The easy thing to help would be --bwlimit=KBPS. > > The disk tunes should be anything that is an even factor of the transfer > size. So 1 transfer (256k) might update 8 blocks, or 64. This helps > keep the VM system cache in check, otherwise you end up flushing blocks > you will reference again to often. > > Setting the transfer size to a large prime number is about the worst > thing you can do, then set disk block size to a larger prime and > see how bad "Bad" can be. :-(
KSB, thanks for your answer ! So I will test with chunks of 256K, 512K and 1024K. Should I leave FS blocks to 4K, or increase them to let's say 256K ? What about RAID type ? I was thinking about the "common" RAID5. Thx ! Ben -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
