Re: NFS

Alan Cox (alan@cymru.net)
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