Re: [Nbd] 2.8.8 upcoming
- To: "Wouter Verhelst" <wouter@...3...>
- Cc: nbd-general@lists.sourceforge.net
- Subject: Re: [Nbd] 2.8.8 upcoming
- From: "Mike Snitzer" <snitzer@...17...>
- Date: Thu, 9 Nov 2006 15:39:08 -0500
- Message-id: <170fa0d20611091239h7f5b2be2r64e2b7d07a70d2e8@...18...>
- In-reply-to: <20061109160821.GA20477@...39...>
- References: <20061109160821.GA20477@...39...>
On 11/9/06, Wouter Verhelst <wouter@...3...> wrote:
Hi all,
I recently uploaded 2.9.0 to sourceforge, which replaced 2.8.7 as the
latest "stable" release. This will mean I'll drop support for the 2.7
branch (unless people come up with really compelling arguments).
We never tracked down the nbd-server 2.8.6 __lll_mutex_lock_wait
issue. The "nbd-server 2.8.6 hangs on nbd-client reconnect" thread
just died off after I posted: I'm blaming glib... ndb 2.7.7's
nbd-server (non-glib, uses select) works perfectly fine!
So if you remove the 2.7.x branch (I assume from sf.net not svn right?
or are they one in the same?) it would seem to imply all future (2.8.x
or 2.9.x) users _could_ hit this nbd-server deadlock on nbd-client
reconnect (after the nbd-client was forcibly killed while performing
heavy IO). This was seen on RHEL4U3 x86_64... so it _could_ be a
redhat-only glib bug but...
My experience (on large commercial nbd deployments) is that nbd-server
2.7.7 (with nbd-client 2.8.5) is trully "stable". I can't say the
same for nbd-server 2.8.x on up. I could try 2.9.x out again to see
if this issue has magically been fixed but its easier to just
steer-clear of the seemingly overly complex glib-based nbd-server(s).
Mike
Reply to: