[OpenAFS] Re: File creation delays

[John W. Sopko Jr.]

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."<sopko@cs.unc.edu> 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