Re: fsmonitor on linux is triggered due to unison changes its fingerprint cache

Ulrich Gemkow <[email protected]> writes:

> We use unison (text UI) to synchronize the homedirs of our users
> with our file server. We use "-repeat watch" to only start a
> synchronize run when something is changed in the replicas.
>
> In this mode the fsmonitor is triggered about every second by a
> change in the homedir. Caused by this unison is triggered too.
> This happens even when the user has nothing changed in the homedir
> (on both sides).
>
> Some digging into this using an inotify watch tool on the file
> server shows that the trigger is caused by unison itself, which
> accesses its fingerprint cache (File fp*) about every second.
>
> The inotify watch tool shows this sequence about every second:
>
> # ~/.unison/homesync/ OPEN fpd51d53afbd71ea49fcec7a981a36e25f
> # ~/.unison/homesync/ ACCESS fpd51d53afbd71ea49fcec7a981a36e25f
> # ~/.unison/homesync/ CLOSE_NOWRITE,CLOSE fpd51d53afbd71ea49fcec7a981a36e25f
> # ~/.unison/homesync/ OPEN fpd51d53afbd71ea49fcec7a981a36e25f
> # ~/.unison/homesync/ MODIFY fpd51d53afbd71ea49fcec7a981a36e25f
> # ~/.unison/homesync/ CLOSE_WRITE,CLOSE fpd51d53afbd71ea49fcec7a981a36e25f
>
> Please note that the .unison dir is excluded from syncing (but this
> is not known by the fsmonitor). So nothing is synced, unison on the
> client side says
>
> # Looking for changes
> #   Waiting for changes from server
> # Reconciling changes
> # Nothing to do: replicas have not changed since last sync.
>
> which is correct :-)
>
> I would expect that the fsmonitor is not triggered when there are
> no changes in the replicas.

There's a lot of complexity in "not triggered".  Keep in mind that I
don't personally use fsmonitor so take this with a grain of salt; I'm
describing my take because experience says that saying something wrong
crisply will bring a rapid correction, while expressing that I don't
know won't lead to a correct and crisp statement :-)

  - accesses that are read only should be ignored by fsmonitor and not
    reported to unison
  - modifications should be reported to unison
  - unison should examine the reported modfication in light of the
    ignore list, and if it's to a file that wouldn't be synced, ignore
    it.

You are saying "fsmonitor is triggered" but I don't know what that
means, precisely.  I suggest you enable debugging in fsmonitor and
unison.

It sounds like there is a cycle

  fsmonitor says there is a change
  unison scans, and rewrites the fp file
  fsmonitor notices this write

> This is not a big deal but prevents our notebooks from going in low
> power mode. A very rough measurement has shown that this is
> significant on battery life time.

Sure, it's definitely not what should happen.

> We use unison 2.53.7 on Linux (Debian 13) using the downloadable
> package from github for ubuntu. We use ssh as connection method,
> unison is compiled with ocaml 4.14.2
>
> Do other users see the same? Is there an easy solution for this?
> I do not understand why unison touches its fingerprint cache when
> nothing changes.

If unison is told by fsmonitor that something happened, it will rescan,
and that could result in writing the same data.  You have a good point,
and perhaps unison should refrain from writing if there isn't a change.
I am guessing though, that the mod time of the fp file has changed.

What does ls -lT of the fp file show, over brief intervals?

It feels like there is a failure of the exclude mechanism to work,
somehow, in your system setup.  I think the path to resolving this is
figuring out why that's happening.

You didn't post your profile (or a sanitized version).

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].