Many months ago (9/16/1998), Troy Benjegerdes said:

| Untarring linux-2.1.121 on nfs:
| 4.18user 3.97system 1:14.74elapsed 10%CPU (0avgtext+0avgdata 0maxresident)k
| 0inputs+0outputs (3163major+9197minor)pagefaults 0swaps
|
| Untarring linux-2.1.121 on coda:
| 4.44user 2.84system 1:00:55elapsed 0%CPU (0avgtext+0avgdata
| 0maxresident)k 0inputs+0outputs (206major+9197minor)pagefaults 0swaps

And just now I tried:

Untarring linux-2.1.122 on coda:
4.71user 3.07system 28:16.12elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (3185major+9204minor)pagefaults 0swaps

I guess the difference is probably related to the fact that my machine 
has a PII-400 processor, and a 100B-T ethernet connection to the server. 

We have not been concentrating on improving the speed, but mostly on
improving the overall stability of the system. First of all, there are
still about 3 RPC's for each created file, and when the write disconnected
operations, or it's extension writeback caching, get really stable there
will be only 
1 RPC for about 100 file creations.

Now that will ofcourse not give a 300 fold speed increase, because we
are not just blocking on the RPC calls, but it should become a bit faster 
for the client-server traffic and a lot faster for what the user observes.

i.e. here are some actual measurements in write-disconnected mode:

Untarring linux-2.1.122 on coda:
4.83user 3.35system 2:36.85elapsed 5%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (3200major+9204minor)pagefaults 0swaps

And then about 12 minutes while the changes are being trickled back to the
server, but the user isn't forced to wait for this.

Jan