Re: [Nbd] [RFC 4/4] nbd: Add support for nbd as root device

[Wouter Verhelst <w@...112...>]

On Fri, Feb 06, 2015 at 08:32:12AM +0100, Markus Pargmann wrote:
> On Thu, Feb 05, 2015 at 09:24:00AM +0000, Alex Bligh wrote:
> > 
> > On 5 Feb 2015, at 08:18, Wouter Verhelst <w@...112...> wrote:
> > 
> > > I had been thinking it might make sense for NBD to have something like
> > > an "nbd master", in the style of /dev/pts/ptmx; a /dev node whom you ask
> > > for an NBD device assignment, and which replies with a name, or
> > > something along those lines.
> > 
> > /dev/tun is another similar (and from what I recall slightly simpler)
> > precedent.
> 
> Yes I also thought about something similar for nbd.

Good, we're thinking along the same lines then :-)

> > > The problem, as ever, is backwards compatibility. If taken to its
> > > logical extreme, this nbdmaster devnode would exist from module
> > > initialization, but things like /dev/nbd0 etc wouldn't be, only when
> > > they are registered. That would not be backwards compatible...
> > 
> > OK, how about this for a route to backward compatibility.
> > 
> > Currently the /dev/nbdN devices only appear when the nbd module is
> > first loaded, via udev or whatever, when the relevant device nodes
> > are created. As standard, 16 of these are created. Access to these
> > devices is inherently racy for the reasons described above. Let's
> > call these 'static' nbd devices.
> > 
> > As a replacement, we make the nbd module create N (where N is
> > a configurable number on the module command line inititially
> > defaulting to 16, but may become zero later) such devices which
> > are static nbd devices. These work as normal. We also let it
> > create dynamic nbd devices (meaning those mediated by the
> > /dev/nbd control device). These could be numbered from N up,
> > though numbering them with a gap might be useful to avoid
> > naive software relying on the old scheme enumerating from
> > 0 upwards.
> > 
> > Userland software, over time, can be converted to use /dev/nbd
> > if it exists to safely create nbd devices. If it finds /dev/nbd
> > is absent, it can fall back to the old route.
> > 
> > Eventually, the default value of N can be reduced to zero,
> > in which case only the new route will work. This default value
> > could be a kernel compile option, in which case a distro that
> > is confident it has refreshed all its nbd software could if
> > it wished reduce N to zero earlier than the mainline kernel.
> 
> I think there should be a kernel deprecation warning with each
> connection of a static nbd device before reducing the default number of
> nbd devices. Otherwise users may experience unexpected difficulties
> after a reboot into a newer kernel. If they get warnings with every nbd
> device connection they may have a look at the new way of allocating nbd
> devices and fix their programs.

That all sounds like a reasonable approach from my POV.

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26