[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