Re: [Nbd] found bug in nbd-server.c, handle_info()
- To: "Menke, Gregory D. (GSFC-582.0)[Arctic Slope Technical Services, Inc.]" <gregory.d.menke@...2917...>
- Cc: nbd-general@lists.sourceforge.net
- Subject: Re: [Nbd] found bug in nbd-server.c, handle_info()
- From: Wouter Verhelst <w@...112...>
- Date: Fri, 12 May 2017 09:20:23 +0200
- Message-id: <20170512072023.ane6ur7unhm2bgia@...3...>
- In-reply-to: <74e82b6f-f9e0-f16b-7f32-3255997fc920@...2917...>
- References: <59135323.90201@...2917...> <20170511084950.6kxxejjbihpz7jpq@...3...> <74e82b6f-f9e0-f16b-7f32-3255997fc920@...2917...>
Hi Greg,
On Thu, May 11, 2017 at 09:53:54AM -0400, Menke, Gregory D. (GSFC-582.0)[Arctic Slope Technical Services, Inc.] wrote:
> Thanks Wouter,
>
> I'm chasing another issue seen both on the trunk and 3.15.2 where an
> apparent deadlock occurs, leaving the nbd device jammed until the
> filesystem op, client and server are SIGKILLed at which point the mount
> can be cleaned up. In this case the tcp connection is running thru an
> ssh tunnel over a wan,
In that case, you're stacking TCP over TCP, which does not work very
well. See http://sites.inka.de/~W1011/devel/tcp-tcp.html for a pretty
good (technical) explanation on why that is the case.
If you stack it over UDP instead (e.g., with OpenVPN), you should be
fine.
--
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
people in the world who think they really understand all of its rules,
and pretty much all of them are just lying to themselves too.
-- #debian-devel, OFTC, 2016-02-12
Reply to: