On Thu, Jun 13, 2019 at 05:45:13PM +0300, Roman Stratiienko wrote: > On Thu, Jun 13, 2019 at 4:52 PM Josef Bacik <josef@xxxxxxxxxxxxxx> wrote: > > > > On Wed, Jun 12, 2019 at 07:31:44PM +0300, roman.stratiienko@xxxxxxxxxxxxxxx wrote: > > > From: Roman Stratiienko <roman.stratiienko@xxxxxxxxxxxxxxx> > > > > > > Adding support to nbd to use it as a root device. This code essentially > > > provides a minimal nbd-client implementation within the kernel. It opens > > > a socket and makes the negotiation with the server. Afterwards it passes > > > the socket to the normal nbd-code to handle the connection. > > > > > > The arguments for the server are passed via kernel command line. > > > The kernel command line has the format > > > 'nbdroot=[<SERVER_IP>:]<SERVER_PORT>/<EXPORT_NAME>'. > > > SERVER_IP is optional. If it is not available it will use the > > > root_server_addr transmitted through DHCP. > > > > > > Based on those arguments, the connection to the server is established > > > and is connected to the nbd0 device. The rootdevice therefore is > > > root=/dev/nbd0. > > > > > > Patch was initialy posted by Markus Pargmann <mpa@xxxxxxxxxxxxxx> > > > and can be found at https://lore.kernel.org/patchwork/patch/532556/ > > > > > > Change-Id: I78f7313918bf31b9dc01a74a42f0f068bede312c > > > Signed-off-by: Roman Stratiienko <roman.stratiienko@xxxxxxxxxxxxxxx> > > > Reviewed-by: Aleksandr Bulyshchenko <A.Bulyshchenko@xxxxxxxxxxxxxxx> > > > > Just throw nbd-client in your initramfs. Every nbd server has it's own > > handshake protocol, embedding one particular servers handshake protocol into the > > kernel isn't the answer here. Thanks, > > > > Josef > > Hello Josef, > > Let me share some of my thoughts that was the motivation for providing > this solution:: > > We choose NBD as a tool to run CI tests on our platforms. > We have a wide range of different BSP's with different kind of images > where using NFSROOT is hard or even impossible. > Most of these BSPs are not using initramfs and some of them are Android-based. > > Taking all this into account we have to put significant efforts to > implement and test custom initramfs and it will not cover all our > needs. > > Much easier way is to embed small client into the kernel and just > enable configuration when needed. > > I believe such solution will be very useful for wide range of kernel users. > > Also, as far as I know mainline nbd-server daemon have only 2 > handshake protocols. So called OLD-STYLE and NEW-STYLE. And OLD-STYLE > is no longer supported. So it should not be a problem, or please fix > me if I'm wrong. > I don't doubt you have a good reason to want it, I'm just not clear on why an initramfs isn't an option? You have this special kernel with your special option, and you manage to get these things to boot your special kernel right? So why is a initramfs with a tiny nbd-client binary in there not an option? Also I mean that there are a bunch of different nbd servers out there. We have our own here at Facebook, qemu has one, IIRC there's a ceph one. They all have their own connection protocols. The beauty of NBD is that it doesn't have to know about that part, it just does the block device part, and I'd really rather leave it that way. Thanks, Josef
