Re: [Nbd] found bug in nbd-server.c, handle_info()
- To: Wouter Verhelst <w@...112...>
- Cc: "nbd-general@lists.sourceforge.net" <nbd-general@lists.sourceforge.net>
- Subject: Re: [Nbd] found bug in nbd-server.c, handle_info()
- From: Alex Bligh <alex@...872...>
- Date: Fri, 12 May 2017 09:23:47 +0200
- Message-id: <FD8E7F64-EB7C-4D7E-97F6-CAC0A47B29C6@...872...>
- In-reply-to: <20170512072023.ane6ur7unhm2bgia@...3...>
- References: <59135323.90201@...2917...> <20170511084950.6kxxejjbihpz7jpq@...3...> <74e82b6f-f9e0-f16b-7f32-3255997fc920@...2917...> <20170512072023.ane6ur7unhm2bgia@...3...>
> On 12 May 2017, at 09:20, Wouter Verhelst <w@...112...> wrote:
>
> 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.
I don't think that's write. nbd over an ssh tunnel over tcp only
has one tcp layer (the one transporting ssh).
--
Alex Bligh
Reply to: