[Unison-hackers] multi-hour delay when sync'ing moderate-size file systems with many path elements

[vouillon]

Hello,

On Wed, Dec 12, 2007 at 07:16:25AM -0500, Seth Teller wrote:
> when using unison to sync moderately-large file systems (several
> thousand files, some of them large) with roughly a dozen unison
> path elements, i observe a very long delay between unison's search
> for updates, and the actual data transfer/sync step.
>
> the delay does not seem to be due to network bandwidth, since
> there is a fast network between the two machines.  it may be
> due to CPU limitations on either end or to disk bandwidth
> limits.

That may be due to network latency too.

> in any event, the delay is so long that often the update fails
> because my kerberos tickets expire, and the processes involved
> lose the the access permissions needed to finish the job.
>
> i have already tried using -fastcheck, which doesn't help.

Can you try to use both the "-fastcheck" and "-pretendwin" options.
It is possible that you are using a filesystem that does not support
inode numbers.  The "-pretendwin" option tells Unison to ignore them
when checking whether a file has been modified.

You can check whether the '-fastcheck" option is working properly by
running Unison with the "-debug verbose" option.  There should be few
lines like this one:
    [verbose]   Double-check possibly updated file

-- Jerome