Re: One new nbd-runner project to support the Gluster/Ceph/Azure, etc
On 2019/4/12 17:36, Richard W.M. Jones wrote:
Let me see if I understand what the nbd-runner project is. I'll try
to explain it, and see if I get this right ...
You have a front end command line tool (nbd-cli), which has various
commands for creating NBD-backed loop devices (/dev/nbdX).
The front end tool does not implement the loop mounts itself, but
instead talks over a socket-based RPC to a server which does the loop
mounting. Also this server (currently) does the processing of NBD
commands from the kernel.
What the server side does is to help manage the backstore's
creation/deletion, premap/postmap,etc and the NBD commands processing,
except that it will also help maintaining the backstore info's and
backup them into one json file, like the targetcli does, and also the
cache to quick querying, this are the main difference with qemu-nbd in
the server side, and this will help us restore the backstores very
easily when the server restarted, especially if there are thousands of
devices exist. Another advantage is that we can keep the code as small
as < 3k.
And the nbd-cli command side is doing the NBD device's mapping and settings.
With nbd-runner we can make the integration as simple as possible by
using only the nbd-runner utils, this is why the other team want it.
Assuming that's a correct description of the program, I'm saying that
instead of implementing an NBD server yourself, use an established NBD
server. qemu-nbd already supports Gluster, Ceph and iSCSI so could be
used immediately. nbdkit could support those if you wrote the
additional plugins, which is not difficult.
These existing servers already support far more of the NBD protocol
than you have implemented and are already battle-tested both with the
Linux kernel NBD client code and (for qemu-nbd) with Gluster, Ceph and
iSCSI.
Yeah, that's true. The qemu has supported almost all the exist protos,
but as above said, we just want one common tool that could work as the
iSCSI utils does and at the same time to make one quick release, before
we have stuck in qemu core code for more than one year about the LIO stuff.
Currently the nbd-runner is ready and we have tons of test about the
nbd-runner too.
Obviously this is free software and you're free to do what you want,
but this would be what I would do, and would seem like it saves you a
lot of effort in the long term ...
Certainly we must change the core code to make the qemu-nbd as one
systemd server and add the above features mentioned, which will be 100%
redundant for the qemu use case.
Thanks，
BRs
Rich.
Reply to: