On Thu, Nov 21, 2013 at 09:51:46PM +1030, Brett Lymn wrote:
> I am running coda on a recent NetBSD-current which seems to be running
> fine (a previous rvm problem seems to have vanished with the update
> which is good).  There are a couple of quirks:
> 
> 1) vi always claims that the file on disk is newer than the edited
> buffer.  I suspect this is a stat(2) problem (possibly related to time_t
> being extended) which I will dig into.

Both problems are reintegration related, in this case the client uses
the time that the file was written, and the server probably helpfully
overwrites it with the time the file was reintegrated.

It depends a lot on the application, if an application sends a
CREATE/STORE or just a STORE (create new file and write or overwrite)
the server probably is picking the time the STORE arrived at the server.
If the application sends a CREATE/STORE/SETATTR, we probably end up
using the client's timestamp.

I assume this happens on Linux too, but that the immediate time jumps
tend to be hidden by a more agressive inode/directory entry cache.

Maybe the simplest fix is to always piggy back the local file attributes
along with the store. However that still doesn't solve the following
problem.

> 2) I have noticed that modified directories disappear out of my client
> cache after the changes have been integrated.  I can easily bring them
> back in by accessing the directories in connected mode - I can see a
> fetch of the affected directory happen in codacon when I do this.  It is
> just a bit annoying is all - I effectively have to hoard the modified
> directories otherwise when I go disconnected mode they are not
> available.  This didn't happen in the past but I am not sure where to
> look for this one - I am guessing venus but I am not 100% sure.

It happened in the past occasionally depending on available bandwidth,
now it just predictably happens always. It is sort of a side-effect of
the weak-reintegration. To reduce bandwidth usage between a client and
the servers, instead of sending updates to all servers they are sent to
a single one and then resolution is used to bring the other servers
up to date.

But venus predicts the version vector when the file is locally modified
and at that point doesn't know which server it would reintegrate with
and as such mispredicts what the version vector will look like after
reintegration and resolution. After resolution the server sends a
callback with a different version and the local copy is invalidated.

When you have hoarding enabled, the directory is refetched on the next
hoard walk. The same probably happens for files, but that is probably
less noticable.

Jan