On Mon, 9 Feb 1998, J.A. Harkes wrote:

> 
> In message <Pine.LNX.3.95.980209073018.3750C-100000_at_air.steve.net> you 
> wrote:
>   > 
>   > Sure, when 'make mrproper' fails to remove the directories it 
> thinks are
>   > busy, I just cd into linux/include and rm -rf them manually.
> 
> If that's /usr/src/linux/include, that's bad. AFAIK the linux kernel
> does not install these files, but provides them in the source tar-ball.
> 
>   > As another data point, when copying the source over with 'cp -a 
> linux
>   > /coda/drc/linux', I see a complaint of 'Permission denied' after 
> each
>   > file.  However, I'm unsure what it's complaining about, as the 
> files are
>   > actually (with some spurious exceptions per above) placed on the 
> target.
> 
> Are the owner/group-id of the original files by any chance root.root??
> The cp -a also tries to copy timestamps/permissions AND uid/gid. And
> most likely you don't have or get permission to change the owner to root
> on a Coda fs.

Jan is completely right, and the messages you get will disappear if you
run an auth2 server and log in to Coda.  We are hoping to make Coda more
chown friendly, but it is not high on the to do list.

> 
> BTW. When you're trying to compile the linux kernel on a coda partition
> you probably need to have the symlink /usr/src/linux -> /coda/src/linux.



You can build the linux anywhere.   I build it usually in /home/braam.
All that matters is that /usr/include/{linux,asm,scsi}  point to
..../linux/include/{linux,asm,scsi} in the linux sources (and perhaps even
that doesn't matter). 


> 
> BTW 2. I noticed that the size of the client (venus) cache must be at
> least 2x the size of the resulting program, otherwise linking fails with
> a weird linker error. The linker needs to have all object-files and the
> resulting destination file open, and thus cached locally. So your 20000
> should be fine for anything smaller than 10Mb.

Jan is right.


> 
> As for the copying taking an hour:
>  I get a bandwidth of at least 250kb/s when running both the client and
>  server on a 486/66 with 16MB RAM and 30MB swap. Which results in
>  _copying_ a clean linux-2.1.85 kernel tree in around 3 minutes.
> 

What do you mean with _copying_?  I think what we are interested in here
is tar zxvf linux-2.1.84.tar.gz.  This is slow, but should not take an
hour. 

BTW, neat, I didn't know this.  Jan you could try (with a large cache):

cfs wd  (write disconnect)
tar zxvf linux-...tar.gz
cfs checkservers

and time that!  This is similar to the way the write back caching will do
the work. 

- Peter - 

>  But.. when I do the same over a 115200 bps serial link it would take
>  over 1 hour, if nothing would crash before that ;)
> 
>   > Steve
> 
> Jan
> 
> 
> 
>