On Dec  4, 11:03pm, "Jukka Marin" wrote:
> Then I copied a file from one partition to another on Quantum Empire
> 1080.  No ahsc whines, but the machine was too busy to serve any other
> processes during the copy.  The disk was seeking very quickly (obviously,
> cp uses very small buffers!) and all shells locked up until the copy was
> over.  I couldn't even break cp with ctrl-c! :-(

  Actuall, cp doesn't use any buffer in most cases of copying a file from
disk.  It mmaps() the entire file, and does a single write from the mapped
memory address.  A large transfer is going to be broken up into smaller
segments when being copied from the user address space to the kernel address
space.  In addition to the (relatively) small segments, the entire user
buffer space is going to be non-resident and has to be paged in from the
source file.  I suspect that since the file system block size is 8K (which
is the page size on the Amiga port), the write operation is going to consist
of paging in one page of the source file, copying it to a file system buffer,
and then writing that buffer to the destination file.  That is going to be
very inefficient on the first copy.  If then entire file can fit into the
file system buffers, successive copies of that file should go much more
quickly.

  Since the write operation is one system call, you probably wouldn't be
able to interrupt that write.

> I guess someone tells me to get rid of the IBM drive or something.  Well,
> I wish I could make it work with NetBSD.  It wasn't too cheap. :-I  But

  I would guess that the IBM drive has some quirky behaviour that the NetBSD
driver doesn't deal with.  The only likely way to fix it is if someone who
knows the driver quite well gets a hold of the same type of drive and figures
out what it happening.

> the latter problem is bad, too - obviously, any user can lock up the
> system by simply copying a large file from one place to another.  Is there
> something wrong with my Amiga or is this really a problem?  I have 16 megs

  I'd say it's a problem with the implementation of cp, the file system,
and the virtual memory system.  

Michael

-- 
Michael L. Hitch			INTERNET:  osymh@montana.edu
Computer Consultant
Office of Systems and Computing Services
Montana State University	Bozeman, MT	USA