From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753024AbcFOHAn (ORCPT ); Wed, 15 Jun 2016 03:00:43 -0400 Received: from barbershop.grep.be ([89.106.240.122]:58583 "EHLO barbershop.grep.be" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751190AbcFOHAl (ORCPT ); Wed, 15 Jun 2016 03:00:41 -0400 Date: Wed, 15 Jun 2016 09:00:22 +0200 From: Wouter Verhelst To: Markus Pargmann Cc: Pranay Srivastava , nbd-general@lists.sourceforge.net, linux-kernel@vger.kernel.org Subject: Re: [Nbd] [PATCH v2 4/5]nbd: make nbd device wait for its users. Message-ID: <20160615070022.GA3787@grep.be> References: <3898019.JRqDjBPssX@adelgunde> <2280543.pBfpMHAWFW@adelgunde> <11733279.HlKjcK63G4@adelgunde> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <11733279.HlKjcK63G4@adelgunde> X-Speed: Gates' Law: Every 18 months, the speed of software halves. Organization: none User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 15, 2016 at 08:30:45AM +0200, Markus Pargmann wrote: > Thanks for the explanations. I think my understanding was off by one ;).. > I didn't realize that the DO_IT thread from the userspace has the block > device open as well. Obviously, otherwise it couldn't do an ioctl() to it :-) > I thought a bit about this, does it make sense to delay the essential > cleanup steps until really all open file handles were closed? So that > even if the DO_IT thread exits, the block device is still there. Only if > the file is closed everything is cleaned up. Maybe this makes the code > simpler and we can directly use krefs without any strange constructs. > What do you think? > > This would also allow the client to setup a new socket as long as it > does not close the nbd file handle. That sounds like the behaviour that I described earlier about possible retries for userspace... > Could this behavior be potentially problematic for any client > implementation? I don't think it could, but I'm not sure I understand all the details. What would happen if: - nbd is connected from pid X, pid Y does NBD_DISCONNECT, pid X hangs and doesn't exit? - nbd is connected from pid X, server disconnects while pid Y is trying to access the device, pid X tries to reconnect but it takes a while? > Does it solve our other issue with setting up a new sockets for an > existing nbd blockdevice? It could, depending. -- < 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