[816] in testers
Re: Proper/better (?) fix to VAX afs time skew
daemon@ATHENA.MIT.EDU (daemon@ATHENA.MIT.EDU)
Mon May 21 08:09:57 1990
Date: Mon, 21 May 90 08:09:13 -0400
To: Richard Basch <probe@MIT.EDU>
Cc: epeisach@MIT.EDU, testers@MIT.EDU, bug-afs@MIT.EDU
In-Reply-To: Richard Basch's message of Mon, 21 May 90 07:52:28 -0400,
From: Richard Basch <probe@MIT.EDU>
Date: Mon, 21 May 90 07:52:28 -0400
From: Richard Basch <probe@MIT.EDU>
X-Work: 1 Amherst St. E40-318, Cambridge, MA 02139, (617)253-0100
From: epeisach@ATHENA.MIT.EDU
Date: Sun, 20 May 90 22:23:22 -0400
. . .
There is one concern I have with my change: When writing to a file, the
Dataversion must change so that flushing it will do something. I have
not verified that the code is proper in that area, but I do appear to be
soring files, so I assume it works. (Not really the right assumption so
it needs to be checked). There is another versionnumber that deals with
mod's, so this fix should be examined with this other aspect in
light....
First, let me state from looking at the patch for about an hour and the
various paths, your patch looks correct, with the possible exception of
the write path, which I was unable to trace... apparently, the write
path involves the callback mechanism, and there at least seems to be
code to detect changes on the server as the callback mechanism updates
the f.Unique field of the cache entry. afs_StoreDCache seems to send
out the data to the server, and I suspect that it receives a callback
after that in order to obtain the new version number. Essentially, it
is the FidCmp() macro that detects changes in the f.Unique field (and
the f.Vnode, f.Volume, and f.Cell fields) and appropriate action is then
taken... checking all this logic may take a few weeks.
-Richard
You'll love this one... the only way it could work, from looking at the
client code is:
1) You do a store. DFEntryMod is reset.
2) A callback is received...
f.Unique
f.Vnode
f.Volume
f.Cell
are all updated for the cache entry.
3) Next time an operation is done, the FidCmp() checks will fail because
of the different Unique values. The next ProcessFS() will update the
local concept of the active data version number.
Exactly what happens here is a little bit of a mystery... I am still
trying to see if I missed something in the mechanism that detects that
the latest version is still on that client... the callback does have
"writer" information, and there seems to be some processing based on
that. Anyway, a full analysis will entail examining the callback
mechanism on the server end also.
-Richard
