John W. Sopko Jr. wrote, On 3/17/2010 3:54 PM:
Andrew Deason wrote, On 3/17/2010 3:19 PM:
On Wed, 17 Mar 2010 15:10:49 -0400
"John W. Sopko Jr."<[email protected]> 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.
That will indeed cause problems.
I checked the Windows 7 Firewall and it shows port 7001 is open, looks
like rxdebug to Windows 7 does not work. I can use the linux
"nc -u 7001 152.2.140.215" to connect from the file server.
This is probably another issue.
My mistake, I forgot the "nc" utility does not report errors when
connecting to UDP ports, only tcp. It is a handy tool.
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.
Rxdebug works fine, my problem is fixed! Thanks for all your
help!
In summary. I mount my home directory on Windows 7 AFS client.
I login to many linux servers to do work. Every time I updated
my home dir it could not contact my W7 machines cache manager.
This caused delays or in some cases timeouts.
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. 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.
Yes, but 140.115 can still cause file writes to be slow, if it's having
network problems. What happens when you write to a file (or mkdir,
rmdir, unlink, any write operation), is that the fileserver must contact
any client with a 'callback' or 'callback promise' on that file, to let
the client know that someone has changed the file.
What happens here is that 140.115 has read that directory, and when
140.200 tries to write to that directory (via an rmdir or mkdir), the
fileserver tries to contact 140.115 to let it know that the directory
contents have changed. Since apparently 140.115 is blocking udp port
7001 requests, the fileserver hangs for a few seconds until the request
times out.
You may not notice slowness problems on 140.115, but I'd bet it may show
stale/incorrect data in AFS.
I have seen some of this on the Windows 7 client, but as I said
port 7001 appears to be open. I believe that happens during the
Windows client install. I am mounting a sub-directory
of my home directory on my windows machine with a UNC shortcut
path like: \\afs\cs.unc.edu\home\sopko\tmp. This may be part
of the problem as you describe, a timeout to my windows desktop.
But I am seeing the problem in other mount points that my
Windows machine is not mounting or should be accessing.
Question is why does rxdebug not work to the Windows 7 32 bit
Open AFS client and is port 7001 really working. Darn.
--
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
