Another problem is that in general, only the user or the application knows when it's a problem, and when it's a s l o o w link.
I had to adjust timeouts in the Plan B ns (which does timeout as you suggest) a lot of times, to avoid paranoia regarding "is it a network error, or yet another bug I introduced?". You can use an intermediate file server process to do your timeouts, and run them only when you know there's a problem. That way the kernel you never see a hanged up ns. Also, for what it's worth, I have to say that despite being able to recover the root FS in Plan B, in the end, we ended rebooting the machine when it looses the connection to the FS (dns, and other programs, including the IP config, would suffer badly). Rebooting was just more simple and won against recovering. On 6/29/07, Enrico Weigelt <[EMAIL PROTECTED]> wrote:
* Charles Forsyth <[EMAIL PROTECTED]> wrote: > > The kernel should not hangup if the server is in trouble. > > Perhaps some reasonable timeout would be fine - if we dont > > get an response, abort w/ IO error. > > that will not work. > responses can legitimately be delayed indefinitely. > often the `files' are services and replies arrive > (only) when the work is done. well, then at least that should be interruptible. otherwise an process which reads from such an service will always be totally unresponsive. cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ ---------------------------------------------------------------------
