Re: [9fans] What do I need for a small 9P2000 server @ Linux ?

["Francisco J Ballesteros" <nemo@lsub.org>]

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 <weigelt@metux.de> wrote:
> * Charles Forsyth <forsyth@terzarima.net> 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/
> ---------------------------------------------------------------------
>