On 2 Nov 2000, Tuc <[EMAIL PROTECTED]> wrote:
> > > Say you want to sync from ONE source server to FIVE destination
> > > servers, and you have PERL doing the process management portion
> > > (i.e. forking, waiting, etc...).
> >
> > There will be 5 complete scans of the whole src tree done, building
> > 5 in-memory data structures representing the entire tree, and if the
> > first one started hasn't finished before the last one gets far
> > enough along to start the actual copying, all 5 will be in VM at
> > once.
> >
> > Sorry for all the bad news.
> >
> Would be nice if you could specify a DBM/HASH/etc file that one
> machine can create and the other 4 could read.
Rusty is working on something like this now: essentially a
stat/readdir cache with timeout.
My feeling is that eventually the existing code will suffer metal
fatigue from all these changes. Sooner or later we should pull the
core algorithm out and put it into a new framework and protocol.
Scripting will be an important part of that, though there are still
some fundamental questions undecided, such as:
* support only Python (:-), or multiple languages?
* is the backbone of the thing in C, with hooks for the scripting
language (as in emacs)? or does C just provide the fundamental
operations, which are glued together by the scripting language (as
in PHP).
* what should the command-line syntax for doing this look like?
I'd like to get to at the entry level being able to say
rsync -avz --perl-prefilter='-s $_;' ~/staging somehost:/opt/app
Each filename is passed in to the Perl expression as $_, and the -s
operator checks that it has nonzero size. (Is it right to have a
command-line option for each hook?)
At the top end, it would be nice if people who wanted features like
two-way synchronization or disk-image mirroring could build this in a
scripting language, and perhaps send it back into rsync/contrib/.
--
Martin Pool, Linuxcare, Inc.
+61 2 6262 8990
[EMAIL PROTECTED], http://www.linuxcare.com/
Linuxcare. Support for the revolution.
PGP signature
