From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <8ccc8ba40706291330y69c29a49w55c74b8c96477f00@mail.gmail.com> Date: Fri, 29 Jun 2007 22:30:35 +0200 From: "Francisco J Ballesteros" To: weigelt@metux.de, "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] What do I need for a small 9P2000 server @ Linux ? In-Reply-To: <20070629201330.GA17817@nibiru.local> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070629141216.GA27541@nibiru.local> <20070629201330.GA17817@nibiru.local> Cc: Topicbox-Message-UUID: 8c1eb02e-ead2-11e9-9d60-3106f5b1d025 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 wrote: > * Charles Forsyth 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/ > --------------------------------------------------------------------- >