On Thu, Nov 21, 2013 at 08:54:09AM -0500, Jan Harkes wrote:
> > 
> > 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.
> 

I am not so sure about that because I get the same problem when I run in
disconnected mode too.  When I look in GetVattr() in fso1.cc in the
venus code I can see that atime = mtime = ctime.  I haven't traced back
through the SETATTR code to see where the date comes from but I did
notice if I use touch to update the atime (touch -a) then all the times
get set to the same value.  I believe that for most things atime and
ctime don't need to be set or updated, I don't think that there is much
that cares about those times - mostly mtime is the one everything looks
at.

> 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.
> 

Right... from my testing it seems like atime is getting updated which
updates mtime and ctime too (effectively).  I think vi is caching the
original mtime, atime gets updated so when I ask vi to save the file it
stats the file, finds mtime updated and whinges.

> 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.
> 

Or things just don't notice - the only thing I have come across that
notices is vi (in NetBSD that is actually nvi) so far... vim may behave
differently, I don't know.

> 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.
> 

It probably would be best to do that, keep all 3 times.  Do you think
that would be a difficult/intrusive change?

> > 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.
> 

I will try setting my connection to strong and see if that helps.  I
really only re-integrate over my home wireless which has ample bandwidth
so I don't need bandwidth adaption.

> 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.
> 

Ah..yes, hoarding.  That appears busted for me too when I try to hoard
my working tree I get the following from hoard -d:

vol_getwd: /coda/siren.cust.internode.on.net/working -> 7f000000_at_siren.cust.internode.on.net, , ./working
canonicalize: /coda/siren.cust.internode.on.net/working -> 1, <7f000000_at_siren.cust.internode.on.net, ./working>, /coda/siren.cust.internode.on.net/working
pioctl:Clear(-1, 100): Permission denied
pioctl:Add(7f000000_at_siren.cust.internode.on.net, ./working, 100, 5, 100): Permission denied

At this time coda is in connected mode, I have a coda token and I am the
administrator user for the fs so, to me, the permission denied is
probably a bug somewhere.  For the moment I simulate the hoard using
find and cat > /dev/null to force everything into local cache.

-- 
Brett Lymn
Staple Guns: because duct tape doesn't make that KerCHUNK sound - xkcd.com