From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753619AbcFOJS0 (ORCPT ); Wed, 15 Jun 2016 05:18:26 -0400 Received: from mail-wm0-f67.google.com ([74.125.82.67]:33624 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752767AbcFOJSX (ORCPT ); Wed, 15 Jun 2016 05:18:23 -0400 MIME-Version: 1.0 In-Reply-To: <20160615070022.GA3787@grep.be> References: <3898019.JRqDjBPssX@adelgunde> <2280543.pBfpMHAWFW@adelgunde> <11733279.HlKjcK63G4@adelgunde> <20160615070022.GA3787@grep.be> From: Pranay Srivastava Date: Wed, 15 Jun 2016 14:48:21 +0530 Message-ID: Subject: Re: [Nbd] [PATCH v2 4/5]nbd: make nbd device wait for its users. To: Wouter Verhelst Cc: Markus Pargmann , nbd-general@lists.sourceforge.net, linux-kernel@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 15, 2016 at 12:30 PM, Wouter Verhelst wrote: > 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? In that case pid X would have an error on recv if I'am correct. Then if no other users[like mounts or other user space applications] are present for this device then pidx would 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? Not sure what issue you see in the above case but if I understand correctly, This should again fall in error case [Correct?] as a result of a timeout may be if any requests were in progress. I don't think reconnect will be without any error thrown up user space, not so sure if both sides [server and client] were sitting idle. OR if no timeout was there then things should go OK after a successful reconnect. Multiple processes can still access the device. > >> Does it solve our other issue with setting up a new sockets for an >> existing nbd blockdevice? > > It could, depending. This should be OK. > > -- > < 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 -- ---P.K.S