Path: utzoo!utgpu!jarvis.csri.toronto.edu!qucis!cordy
From: cordy@qucis.queensu.CA (Jim Cordy)
Newsgroups: comp.protocols.appletalk
Subject: Re: HELP!  CAP thru GatorBox -- the Solutions
Keywords: GatorBox, CAP
Message-ID: <208@qusunb.queensu.CA>
Date: 28 Jun 89 12:57:19 GMT
References: <201@qusunitf.queensu.CA> <326@wcc.oz>
Reply-To: cordy@qucis.queensu.CA (Jim Cordy)
Organization: Queen's University, Kingston Ontario
Lines: 34

In article <326@wcc.oz> tom@wcc.oz (Tom Evans) writes:
> ...	
>> ...memory loss bug...
>> Simply drag a folder tree containing
>> upwards of 600 files from your Mac hard disk... 

600 files is called a *backup*, and is the most useful thing I can
think of that a Unix system can do for a large Mac with a fast hard disk,
since true file service through AppleTalk is so slow.

>
>600 files! Egad - that's premeditated cruelty! Of course if the
>GatorBox had a few dozen megs of virtual memory (maybe we can rpc() a
>few megs from an unsuspecting host :-)... 

The memory on the GB has nothing to do with how many files you copy
(or shouldn't).  The Mac calculates the list and sends them one at 
a time anyway, and Unix accepts them one at a time.
The point of copying 600 is to compund the incremental memory loss bug
that the GB has on each file and/or folder access, to the point where it
finally runs out.  You can demonstrate the same bug by just running your
GB for a couple of weeks without a reboot.

By the way, we are now running CAP/aufs successfully through the GB and it
works *great*.  Even if the GB native emulation were working perfectly,
CAP/aufs is still better since it provides separate private mount points
for each user, and is much faster, so what's the point?

Jim
-- 
Prof. J.R. Cordy				cordy@qucis.queensu.ca
Dept. of Computing and Information Science	James.R.Cordy@QueensU.CA
Queen's University at Kingston			cordy@qucis.bitnet
Kingston, Canada K7L 3N6			utcsri!qucis!cordy