On Wed, Aug 06, 2014 at 06:30:34PM +0200, u-codalist-z149_at_aetey.se wrote:
> If possible and not too bothersome, I would be interested to look at
> the corresponding code. Is it available?

I never had it in version control, not sure if I can find it. I am
pretty sure I have upgraded my computer at least twice but the way disks
get larger I tend to copy everything in my old home directory to a
subdir on any new computer.

> > There is more overhead for clients that only cache a few objects per
> > volume, because they end up with callbacks/log updates for every changed
> > object in the volume.
> 
> Curious what was the main reason not to pursue this approach?
> This extra overhead (more data to get and filter) or other problems?

When a client caches even a single object (the root) of a volume, it is
notified when any file in that volume changes and it has to download a
list of all file identifiers that were changed, whether or not the
client is even allowed to access those files. One way to avoid some of
this is to put busy/private volumes behind an acl protected directory so
that typical clients cannot see their roots.

Also because it was proof of concept code, callback log storage on the
servers was as far as I remember unbounded, with disconnections you
cannot tell how long to keep these logs around. A solution for that is
to have a ValidateAttrs fallback when the clients callback log sync
timestamp is older than the oldest entry in the log.

Jan