Re: More frequent dinstall runs and mirror pushes
>> [2] rsync needs a very long time to do the initial filesystem "check",
>> to find out what it actually needs to do. There is currently (afaik)
>> no way to improve that, as rsync simply offers no way to "preseed"
>> the needed information.
> I find that unison handles this situation very well. At each end, it
> keeps a record of the state of things when the last sync was done, so
> it can tell what has changed at each end without any network traffic.
> It is typically used for bidirectional synchronization, but can be told
> to only do transfers in one direction. It needs to be installed at both
> ends.
> I use it to synchronize a 3G directory tree with 42000 files over a DSL
> line, and it takes 1.4s when there are no changes and things are in
> cache.
It's just that the Debian mirrors are not exactly the same copy
everywhere. If they would be then it would be simple to use rsyncs batch
mode and gain a lot from that.
But we do allow mirrors to exclude architectures for example, so one
needs something like i described in my rsync mail:
(THIS and THAT includes all metadata one possibly might need)
THIS is my new filesystem layout,
THAT is my old filesystem layout,
now go, and get THAT to match THIS, but apply all the usual filters I
gave you on cmdline to it
>From my (limited) experience I think unison can't do this.
Also, we need a fairly widely used/spread tool. Our mirrors run on everything
you can imagine, and the very basics we require are currently just
bash and rsync (and egrep if you are a hub pushing leafs).
(We have mirrors running on every kind of Linux you can imagine but also
Solaris, various BSD, i even heard of AIX and HPUX)
--
bye, Joerg
[...]
While Debian is certainly about beer, and in some cases may even be
about free beer, Debian is mainly about free speech.
Reply to: