[OpenAFS] windows openafs cache not updating

[Jonathan Nilsson]

--000e0ce0efb610263604b3ee7f43
Content-Type: text/plain; charset=ISO-8859-1

Hello,

Has anyone had cache inconsistency problems with Windows clients?

Two Windows 7 64-bit OpenAFS 1.7.3 clients are not seeing the same files
when they look at the same volume via two different RW mount points. One
client is making changes, and the other client is just reading the files,
but both are accessing the volume via an RW mount point so that a 'vos
release' won't be necessary. We've seen this problem occasionally before
with earlier versions of OpenAFS too, but never bothered much because it
seemed to fix itself eventually. But now, the only thing that makes the
files show up is a reboot. An "AFS -> flush volume" command from the
context menu does not solve the problem.

Some additional info: the server housing this volume is CentOS 6 64-bit,
OpenAFS 1.4.14. We see messages like these scattered about in the FileLog
for the client that is not seeing the changed files:

FindClient: stillborn client 74024d60(d16fe8cc); conn 180213d0
(host MY.CLI.ENT.IP:7001) had client f402fa30(d16fe8cc)
CB: RCallBackConnectBack (host.c) failed for host MY.CLI.ENT.IP:7001
CB: WhoAreYou failed for host 34015890 (MY.CLI.ENT.IP:7001), error 1

Could these messages be indicating a problem? (They appear frequently in
the logs and I cannot tell if they correspond to specific read or write
actions on the clients.)

-- 
Jonathan.Nilsson at uci dot edu
Social Sciences Computing Services
SSPB 1265 | 949.824.1536

--000e0ce0efb610263604b3ee7f43
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello,<div><br></div><div>Has anyone had cache inconsistency problems with =
Windows clients?</div><div><br></div><div>
Two Windows 7 64-bit OpenAFS 1.7.3 clients are not seeing the same files wh=
en they look at the same volume via two different RW mount points. One clie=
nt is making changes, and the other client is just reading the files, but b=
oth are accessing the volume via an RW mount point so that a &#39;vos relea=
se&#39; won&#39;t be necessary. We&#39;ve seen this problem occasionally be=
fore with earlier versions of OpenAFS too, but never bothered much because =
it seemed to fix itself eventually. But now, the only thing that makes the =
files show up is a reboot. An &quot;AFS -&gt; flush volume&quot; command fr=
om the context menu does not solve the problem.</div>



<div><br></div><div>Some additional info: the server housing this volume is=
 CentOS 6 64-bit, OpenAFS 1.4.14. We see messages like these scattered abou=
t in the FileLog for the client that is not seeing the changed files:</div>


<div><br></div><div>
FindClient: stillborn client 74024d60(d16fe8cc); conn 180213d0 (host=A0MY.C=
LI.ENT.IP:7001) had client f402fa30(d16fe8cc)<br clear=3D"all"><div>CB: RCa=
llBackConnectBack (host.c) failed for host MY.CLI.ENT.IP:7001</div><div>CB:=
 WhoAreYou failed for host 34015890 (MY.CLI.ENT.IP:7001), error 1</div>

<div><br>

</div><div>Could these messages be indicating a problem? (They appear frequ=
ently in the logs and I cannot tell if they correspond to specific read or =
write actions on the clients.)</div><div><br></div><div>--=A0</div><div>

<font face=3D"&#39;courier new&#39;, monospace">Jonathan.Nilsson at uci dot=
 edu</font></div><div><font face=3D"&#39;courier new&#39;, monospace">Socia=
l Sciences Computing Services</font></div>

<div><span style=3D"font-family:&#39;courier new&#39;,monospace">SSPB 1265 =
| <a href=3D"tel:949.824.1536" value=3D"+19498241536" target=3D"_blank">949=
.824.1536</a></span></div><br>
</div>

--000e0ce0efb610263604b3ee7f43--