I was at first, but then removed it. The results were still insufficiently
fast.
Were you using the -c option of rsync? It sounds like you
were and it's
extremely slow. I knew somebody who once went to
extraordinary lengths to
avoid the overhead of -c, making a big patch to rsync to
On Thu, Nov 29, 2001 at 12:59:00PM -0600, Keating, Tim wrote:
I was at first, but then removed it. The results were still insufficiently
fast.
Were you using the -c option of rsync? It sounds like you
were and it's
extremely slow. I knew somebody who once went to
extraordinary
It seems to me the new options --read-batch and --write-batch should go
a long way towards reducing any time spent in creation of checksums and
file lists, so you should definitely give 2.4.7pre4 a try. This is just
a guess since I haven't actually used those options myself, but seems
worth
Keating, Tim [[EMAIL PROTECTED]] writes:
- If there's a mismatch, the client sends over the entire .checksum
file. The server does the compare and sends back a list of files to
delete and a list of files to update. (And now I think of it, it
would probably be better if the server just sent
to enable faster mirroring of large
filesyst ems
Keating, Tim [[EMAIL PROTECTED]] writes:
- If there's a mismatch, the client sends over the entire .checksum
file. The server does the compare and sends back a list of files to
delete and a list of files to update. (And now I think
Keating, Tim [[EMAIL PROTECTED]] writes:
Is there a way you could query your database to tell you which
extents have data that has been modified within a certain timeframe?
Not in any practical way that I know of. It's not normally a major
hassle for us since rsync is used for a central
