At 17:45 30/06/2002 -0700, you wrote:
I dislike flaming and i don't intend my comments as flame
but you have made some statements that at face value are
problematic. Perhaps you could correct my misunderstanding.
[...]
Well, the first comment: during my work, I wanted to verify that the
At 09:19 01/07/2002 +1000, you wrote:
[...]
This relies on optimal block size being related for a set of files. I'm not
sure that this heuristic actually applies, and I don't know how much benefit
this would buy for all the complexity it would add.
I think that many clients do not care about
On Tue, Jul 02, 2002 at 11:06:30AM +0200, Olivier Lachambre wrote:
At 09:19 01/07/2002 +1000, you wrote:
[...]
This relies on optimal block size being related for a set of files. I'm not
sure that this heuristic actually applies, and I don't know how much benefit
this would buy for all the
At 17:09 30/06/2002 -0700, you wrote:
Olivier,
Well, the first comment: during my work, I wanted to verify that the
theorical optimal block size sqrt(24*n/Q) given by Andrew Tridgell in his
PHd Thesis was actually the good one, and when doing the tests on randomly
generated modified files
Hello,
Another French student in the rsync mailing list. I have been working on
rsync this year for a documentation project for school and I would like to
give some comment about rsync block size optimization first, and then to
submit a way to make rsync choose by itself the optimal blocksize
On Sun, Jun 30, 2002 at 06:23:10PM +0200, Olivier Lachambre wrote:
[...]
Well, the first comment: during my work, I wanted to verify that the
theorical optimal block size sqrt(24*n/Q) given by Andrew Tridgell in his
PHd Thesis was actually the good one, and when doing the tests on randomly
Olivier,
Well, the first comment: during my work, I wanted to verify that the
theorical optimal block size sqrt(24*n/Q) given by Andrew Tridgell in his
PHd Thesis was actually the good one, and when doing the tests on randomly
generated modified files I discovered that the size
I believe that the compression option turns on compression of transfered
data, including file lists, instruction streams etc. Even with compression
turned off, the miss data in the delta is still compressed.
nope!
Compression only compresses file data, not file lists etc. The file
lists are
mailing list. I have been working on
rsync this year for a documentation project for school and I would like to
give some comment about rsync block size optimization first, and then to
submit a way to make rsync choose by itself the optimal blocksize when
updating a large number of files.
Well
What flags or options could be used to optimize rsync? I have seen a
huge amount of cpu and memory be used in this process we have.
I think using the --delete function is a lot of overhead.
The options we normally use are -avrpg
I would like to reduce all unnecessary processing and overhead.
On Wed, Oct 03, 2001 at 11:50:07AM -0700, Jason Helfman wrote:
What flags or options could be used to optimize rsync? I have seen a
huge amount of cpu and memory be used in this process we have.
I think using the --delete function is a lot of overhead.
The options we normally use are
11 matches
Mail list logo
