Subject: [netatalk-admins] One Server, 2 Volumes and a big file

From: Harald Roelle <[email-masked]>
Date: Thu, 21 Jan 1999 15:47:55 +0100

Right now I encountered the following problem:

I´ve got one server which exports two volumes.

From the Finder I tried to copy a big file (about 600M) from one volume to
the other one.

What happened:
After the ´copy´ window opened the mac was blocked (no progress bar in the
window, watch cursor active).
Looking at my Linux box I saw that copying was in progress. It seemed to be
done locally, disk to disk (according to the speed the file grew without
heavy network load). But after some time my mac complained, that the
connection to the server was lost and therefore the copy can´t be done.

I guess netatalk does the copy locally (which is fine) but ´forgets´ to
tell the mac what´s going on. (a very high level view)

I don´t know very much about AFP in detail, but I wonder if it´s possible
at all to have such ´progress notifications´.

My setup:
Linux 20.0.36 + netatalk+asun on a K6/200
MacOS D1-8.1 (German) on a PowerBook G3 Series
10 MBit/s Ethernet

Has anyone seen this before? Any fixes?

Thanks in advance,
Harry

--------------------------------------------------------------------------------
  Harald Roelle                                 <mailto:[email-masked]>
                                                   <http://www.roelle.i3w.com>

---

From: ian reinhart geiser <[email-masked]>
Date: Thu, 21 Jan 1999 18:38:12 -0600 (CST)

> Has anyone seen this before? Any fixes?

	yes i have seen this before...
	on my linux box it seems like it copies it
	in RAM...

 	after a file is about 60+ megs on the server
	the box will puke and the copie fails...

	-ian reinhart geiser

.-----------------------------------------------------------.
|[]                   NeXT Generation                    [X]|
|--------------------------,--------------------------------.
|  PC Network Specialist,  | Office:	CCSD Data Center    |
|  Macintosh Specialist @  | Phone:     414.277.4528        |
|  Milwaukee School of     |	                            |
|        Engineering       |--------------------------------|
|                          |                                |
|   ian reinhart geiser    | phone:   414.220.9683          |
|   Apt #510A              | email:   [email-masked]      |
|   1029 N Jackson St      | web:     www.msoe.edu/~geiseri |
|   Milwaukee, WI 53202    |  NeXT/Be/Cyberdog Mail okay!   |
|                          |   MIME or BinHex prefered      |
|--------------------------'--------------------------------|
'-----------------------------------------------------------'

---

From: Chris Irvine <[email-masked]>
Date: Thu, 21 Jan 1999 17:15:08 -0800

> Has anyone seen this before? Any fixes?
This is somewhat normal.  The AppleShare client is able to essentially disconnect from a cross-volume copy.  This is your problem.  An oversimplified description seems to follow these lines: Normally the client ask for ONE file to be copied.  The client and server must be aware that both volumes reside on the same server.  (A similar situation with a Finder duplicate.)  The server copies the file locally.  This could show as a "cp" process.  When finished the client is notified, and the client may ask for another file to be copied.  I don't know if there is an option in the AFP spec to allow for a "I'm 30% done copping your file" type packet.

Here is what I would try to solve the problem: Find a file that is just big enough to cause the client to time out.  Then use the "AppleShare Client Setup" tool to turn up some of the client time-outs. If the file copies successfully, then calculate a reasonable time-out based on the size of your files.  Hopefully there isn't a server side time-out problem.

Good luck,
Chris

--------------------------------------------------------------
Chris Irvine              On-line store-> http://www.tfaw.com/
Information Systems Technician             phone: 503-652-8815
Dark Horse Comics, Inc.              http://www.darkhorse.com/
PGP Key ID: 0x0263648A
PGP F.P.  8CEF 1BC8 F763 DF79 6F38  3156 EA30 50DF 0263 648A

---

From: a sun <[email-masked]>
Date: Thu, 21 Jan 1999 17:35:34 -0800 (PST)

> Right now I encountered the following problem: =20 I=B4ve got one
   >server which exports two volumes.  =20 From the Finder I tried to
   >copy a big file (about 600M) from one volume t= o the other one.
   >=20 What happened: After the =B4copy=B4 window opened the mac was
   >blocked (no progress bar i= n the window, watch cursor active).

it turns out that i was wondering about this in the case of
implementing FPCatSearch as that could conceivably result in long
delays and subsequent timeouts. the solution that immediately pops
into mind is to split the afpd loop into a couple threads.  as long as
we're extra careful not to actually interrupt an actual response, we
should be fine. 

in case your interested in what's happening, the FPCopyFile code
should actually handle tickles being sent to the client all
right. however, it's most likely not responding to tickles due to it
servicing the FPCopyFile request. having a couple threads should
make that possible.

so, here's the big question: what systems have pthread support? i'm
pretty sure linux, *bsd, and solaris do, but i don't think sunos and
ultrix do. i suppose i can just not create separate threads on those
platforms. 

-a

---

From: "Paul J. Schinder" <[email-masked]>
Date: Sat, 23 Jan 1999 21:59:55 -0500

At 5:35 PM -0800 1/21/99, a sun wrote:

}
} so, here's the big question: what systems have pthread support? i'm
} pretty sure linux, *bsd, and solaris do, but i don't think sunos and
} ultrix do. i suppose i can just not create separate threads on those
} platforms.

SunOS definitely does not.  Is there any chance you can simply fork off
another process to do the job?

}
}
} -a

---
Paul J. Schinder
NASA Goddard Space Flight Center
Code 693, Greenbelt, MD 20771
[email-masked]

---

From: [email-masked]
Date: Sun, 24 Jan 1999 11:29:45 -0500

> From:    a sun <[email-masked]>
> To:      [email-masked]

> the solution that immediately pops
> into mind is to split the afpd loop into a couple threads.

Since there are so few cases that need multiple threads, I'd suggest
rewriting catsearch and copyfile to periodically stop their tasks and
pay attention to the clients.

:wes

---

From: a sun <[email-masked]>
Date: Sat, 23 Jan 1999 20:44:55 -0800 (PST)

actually, my current idea is to use asynchronous io if that's
available. that should also improve interactive response as well as we
can just let the few operations that might take forever to run
separately from everything else.

as netatalk doesn't currently have autoconf support (hint hint), i
guess i'll add some option to turn it on. starting another process
seems awfully wasteful. in addition, there's the problem of getting
back status information from that process. i suppose i could always
use the exit code, but that's pretty ugly. getting a completion signal
just seems so much nicer.

in any case, i'll see what i can do to FPCopyFile so that it doesn't
timeout. until i get some kind of asynchronous io support in, you'll
still be unable do to anything while the copying is going on, but
hopefully you won't get timeouts. basically, i'll probably just turn
off afpd's tickle timeout checking during an FPCopyFile.

-a