On Thu, Aug 08, 2002 at 11:05:44AM -0500, Nathan Davis wrote: > karl bongers wrote: > > I figured out what is happening with my big file transfers. > > I'm pushing the file from a Duron 750Mhz box to a Cyrix 300Mhz > > box. The faster machine swamps out the slower one which then > > drops frames. The default NFS timeout doesn't handle this > > well, while a TCP transfer has a more aggressive/shorter timeout. > > My throughput tests didn't take into account the disk IO activity > > so showed much better capability. > The server (the faster box if I'm interpretting this right) should only be > sending data in response to read requests from the client. Therefore, I don't > think this should be a problem. If the client is getting can't keep up, then > it should throttle back on sending requests. Packets could be dropped, > however, if the server is being swamped with requests. No, the slower box is running the NFS daemons(server), the fast box is remote mounting the IDE drive and then copying the file. I'll try it the other way around tonight just for curiousity sake. On the slow box I swapped NIC cards, tried a crossover cable, all act similiarly(dropped frames periodically during the transfer). > > Concerning my whining about NFS hanging on me, this appears to > > be me doing something stupid. It only happens if I have a > > client box try and access a server that has been disconnected. > > Then the client app hangs, and when I shut down it will hang > > forever at "Unmounting NFS filesystems" stage. > > I also found that if I kill the "login" process associated with the > > app that hangs, then it will shut down fine. > I think it may shutdown by itself, but just take a very long time (because of > the long time-out period). Maybe not, though if files on the share are > currently "in use" by the client. When mounting you can use a "intr" option, which allows apps to be interrupted/killed, otherwise they wait forever. The way I tested it was to disconnect the ethernet, then do a "ls /mnt/nfs_box". The app then hangs. Without "intr" option, you can't kill it. After I kill the "login" process associated with it, I was able to shutdown. After killing "login", "ls" still appears in the list from ps -e, and you still can't kill it(yet shutdown works fine). Maybe its a zombie process? I believe at least once that it had waited all night long without shutting down(waiting for the umount). #### Skuby Doo and the pengiun kill the zombie process ####