> I think that the part where we associate parent directory information > during lookup instead of getattr is already done in some experimental > code which changes the way conflicts are expanded.
OK, we'll sit tight and wait for that.
> > I don't understand why the versions are different after the delayed
> > COP2 hits. When the VVs are set to be identical, then the COP2 hits, it
> > should hit with the same VV. So why would this cause a conflict?
>
> COP2 indicates on what other servers an operation completed, so it
> updates the slots in the version vector that do not refer to the local
> server. Consider a volume with two replicas during a normal operation,
>
> server1 server2
> Initial state [0 0] [0 0]
> Store foo [1 0] [0 1]
> COP2 [1 1] [1 1]
>
>
> Now when we add the resolve before the COP2
>
> server1 server2
> Initial state [0 0] [0 0]
> Store foo [1 0] [0 1]
> Resolve [1 1] [1 1]
> COP2 [1 2] [2 1]
Huh. OK, thanks for explaining how this works. I don't suppose we
could then auto-resolve again so that we wound up with this:
server1 server2
Initial state [0 0] [0 0]
Store foo [1 0] [0 1]
Resolve [1 1] [1 1]
COP2 [1 2] [2 1]
Resolve [2 2] [2 2]
?
> Strange, obtaining new tokens shouldn't interrupt any pending RPC2
> calls. The connection should get dropped once the reply is received and
> the next operation will setup up a new connection based on the new
> token.
It may not be. This was an assumption based on those log messages and
a guess from the server crash. I could be off-base here.
> Can't do that, every token contains a unique key which is used to
> negiotiate session keys of the connections. We can't keep using the
> old token/key. Besides the new token might be for a different Coda
> identity so we might have completely different access rights.
Okay.
--
Patrick Walsh
eSoft Incorporated
303.444.1600 x3350
http://www.esoft.com/
signature.asc
Description: This is a digitally signed message part
