From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GuSQZ-0007kf-9Y for qemu-devel@nongnu.org; Wed, 13 Dec 2006 06:37:35 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GuSQX-0007kO-Lt for qemu-devel@nongnu.org; Wed, 13 Dec 2006 06:37:34 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GuSQX-0007kJ-Gw for qemu-devel@nongnu.org; Wed, 13 Dec 2006 06:37:33 -0500 Received: from [62.219.232.206] (helo=il.qumranet.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GuSQX-0000Vh-9z for qemu-devel@nongnu.org; Wed, 13 Dec 2006 06:37:33 -0500 Message-ID: <457FE5EE.4000704@qumranet.com> Date: Wed, 13 Dec 2006 13:37:18 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: NBD server for QEMU images References: <20061212124803.47702.qmail@web52708.mail.yahoo.com> <457EC621.6000701@codemonkey.ws> <457F0D61.90008@codemonkey.ws> In-Reply-To: <457F0D61.90008@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Anthony Liguori wrote: >> >> Mounting a partition being served on the same host as read-write can >> cause deadlocks. From nbd-2.9.0 README file: > > This text is pretty old. Is this still valid? This would imply that > things like loop can result in dead locks. I don't see why flushing > one device would depend on the completion of another device. > Otherwise, if you had two disk adapters, they would always be > operating in lock step. > > As I've said, I've never seen a problem doing-write with nbd on > localhost. A deadlock can happen under heavy I/O load: - write tons of data to nbd device, data ends up in pagecache - memory gets low, kswapd wakes up, calls nbd device to actually write the data - nbd issues a request, which ends up on the nbd server on the same machine - the nbd server allocates memory - memory allocation hangs waiting for kswapd I submitted a patch/workaround for this some years ago (for a similar problem with a local mount to a userspace nfs server). -- error compiling committee.c: too many arguments to function