Messages in this thread | | | From | Alan Cox <> | Subject | Re: NFS | Date | Wed, 6 Mar 1996 11:30:15 +0000 (GMT) |
| |
> client# ls > > and the client hangs forever on waiting for disk state. > (should timeout, at least)
No. If you want a timeout mount with the "soft" option. By default NFS waits forever as it would for a physical disk that was mindbogglingly slow. Many people prefer a long hang to corrupt files.
> client# mount server:/usr/local/other /usr/local/other > mount: server:/usr/local/other allready mounted or /usr/local/other busy
Its already mounted, NFS is stateless so a server crash isnt a problem, your program should just recover and carry on after a reboot.
> client# mount -o remount /usr/local/other > aha, sucess! > client# cd /usr/local/other > client# ls > and it hangs.
Thats a funny one, and probably a bug.
> 1) Umount of NFS should allways work, regardless of in use or not. It can't. > 2) Anything on NFS mounted partitons can get it dropped out from under them, > without hanging the machine (EIO or similar) See the "soft" option, and also "intr".
> 3) Remount of NFS partition should re-contact the server and really > re-establish the connection, instead of just returning sucess.
NFS is stateless, it has no concept of a remount.
> Also, general timeouts on waiting for disk, and processes waiting on disk > should be killable. (Zombies too...)
Processes in state 'D' cannot be killed, they are in that state as they are in a kernel wait that cannot be recovered from. A zombie is already dead.
> How bad would it be to have a process waiting on disk activity to die? > I suppose you would need to put something there to catch the return from > the disk, but that would only eat a buffer -> /dev/null, so thats no biggie > (is it?)
It would not be pretty. You can if you feel like it go and work through all the sleep_on and interruptible_sleep_on code and migrate the former to the latter adding all the recovery stuff - in many cases thats a big job.
Alan
| |