Jeffrey Altman wrote, On 3/17/2010 3:35 PM:
On 3/17/2010 3:10 PM, John W. Sopko Jr. wrote:
Hmmm, 152.2.140.115 is my Windows 7 desktop, I use an ssh Secure CRT
client to ssh from 152.2.140.115 to the various linux servers like
152.2.140.200. I am running the OpenAFS Windows client on my W7
desktop and it seems to work fine, copy, create, delete files. So
I assumed the firewall was open, I just did
"rxdebug 152.2.140.115 7001 -version" from the file server and
it hung. I will look into opening the firewall.

Which firewall product?  OpenAFS knows how to register itself
with the built-in Microsoft firewall.  It does not know how to
detect and register with third-party firewalls.

We are using Only Windows 7 firewall. The problem is that
port 7001 was in the Domain and Public profiles but not
the Private profile. I enabled the Private profile for
port 7001 and that fixed. I need to work with our Windows
group to get our firewall rules straightened out.

Fixing the firewall issue fixed the problem.


I would think that this would not matter since I am ssh'ing from
my 152.2.140.115 W7 machine to linux clients and they are having the
problem.

If you access a directory from the Windows machine, the Windows
machine will be issued a callback promise from the file server.
The file server guarantees that for the next N seconds, if anyone
else attempts to modify the contents of the directory (or file)
the file server will contact the Windows machine to notify it that
the contents of the cache may no longer be valid.

Callbacks are sent for other operations such as dropping file
locks, changing ACLs, etc.

If the file server cannot deliver the promised cache invalidation,
then it will try for a while before it gives up.  This is the
mechanism that AFS uses to preserve cache coherency.

I just logged into my linux desktop 152.2.140.200 and did a
mkdirt and got the delay problem, it is running openafs 1.4.12. From the
file server that I am accessing to the client having issues
rxdebug shows port 7001 is open:

Delays will be seen from any system that attempts to perform
an operation that requires a callback if the callback cannot
be delivered.

Jeffrey Altman


--
John W. Sopko Jr.               University of North Carolina
email: sopko AT cs.unc.edu      Computer Science Dept., CB 3175
Phone: 919-962-1844             Fred Brooks Building; Room 140
Fax:   919-962-1799             Chapel Hill, NC 27599-3175
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info

Reply via email to