> On Jan 21, 2017, at 7:12 AM, Wouter Verhelst <w@xxxxxxx> wrote: > >> On Fri, Jan 20, 2017 at 04:56:52PM -0500, Josef Bacik wrote: >> This patch mirrors the loop back device behavior with a few changes. First >> there is no DEL operation as NBD doesn't get as much churn as loop devices do. >> Secondly the GET_NEXT operation can optionally create a new NBD device or not. >> Our infrastructure people want to not allow NBD to create new devices as it >> causes problems for them in containers. However allow this to be optional as >> things like the OSS NBD client probably doesn't care and would like to just be >> given a device to use. > > Don't be so sure :-) > > I agree that having a control device for NBD is useful and would make > certain things much easier. If that's added, then I'll move to using > that as a way to control the device rather than opening a device and > dealing with it that way. In fact, at some point in the past I did > suggest something along those ways myself; it's just not happened yet. > > Obviously though this would require an intermediate situation in which > the control master would be available as well as (optionally perhaps) > the old way where you open a specific device node, so that we don't > break existing implementations before they've had a chance to follow > suit. Sorry I wasn't super clear. This doesn't change anything about how the devices are setup, it just means if you do max_nbds=0 you can dynamically add more as you need them, and you can find unused nbd devices easily instead of making the user specify them. When I get home tonight I'll push my nbd-client patch so you can see how I use it. Thanks, Josef-- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
