[OpenAFS] Re: File creation delays

John W. Sopko Jr. sopko@cs.unc.edu
Wed, 17 Mar 2010 15:54:22 -0400


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.


>> 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