[OpenAFS] Re: File creation delays
John W. Sopko Jr.
Thu, 18 Mar 2010 07:58:19 -0400
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@example.com> wrote:
>>> Hmmm, 184.108.40.206 is my Windows 7 desktop, I use an ssh Secure CRT
>>> client to ssh from 220.127.116.11 to the various linux servers like
>>> 18.104.22.168. 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 22.214.171.124 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 126.96.36.199" 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
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
>>> 188.8.131.52 W7 machine to linux clients and they are having the
>>> problem. I just logged into my linux desktop 184.108.40.206 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