|
On 2019/3/25 14:36, Vijay Bellur wrote:
Hi Xiubo,
On
2019/3/21 11:29, Xiubo Li wrote:
All,
I am one of
the contributor for gluster-block[1]
project, and also I contribute to linux kernel and
open-iscsi project.[2]
NBD was
around for some time, but in recent time, linux
kernel’s Network Block Device (NBD) is enhanced and
made to work with more devices and also the option
to integrate with netlink is added. So, I tried to
provide a glusterfs client based NBD driver
recently. Please refer github issue #633[3],
and good news is I have a working code, with most
basic things @ nbd-runner project[4].
This is nice. Thank you for your work!
As mentioned the nbd-runner(NBD proto) will work in
the same layer with tcmu-runner(iSCSI proto), this is
not trying to replace the
gluster-block/ceph-iscsi-gateway great projects.
It just provides the common library to do the low
level stuff, like the sysfs/netlink operations and the
IOs from the nbd kernel socket, and the great
tcmu-runner project is doing the sysfs/uio operations
and IOs from the kernel SCSI/iSCSI.
The nbd-cli tool will work like the
iscsi-initiator-utils, and the nbd-runner daemon will
work like the tcmu-runner daemon, that's all.
Do you have thoughts on how nbd-runner currently
differs or would differ from tcmu-runner? It might be
useful to document the differences in github (or
elsewhere) so that users can make an informed choice
between nbd-runner & tcmu-runner.
Yeah, this makes sense and I will figure it out in the github.
Currently for the open-iscsi/tcmu-runner, there are already many
existing tools to help product it, and for NBD we may need to
implement them, correct me if I am wrong here :-)
In tcmu-runner for different backend storages, they
have separate handlers, glfs.c handler for Gluster,
rbd.c handler for Ceph, etc. And what the handlers
here are doing the actual IOs with the backend storage
services once the IO paths setup are done by
ceph-iscsi-gateway/gluster-block....
Then we can support all the kind of backend storages,
like the Gluster/Ceph/Azure... as one separate handler
in nbd-runner, which no need to care about the NBD low
level's stuff updates and changes.
Given that the charter for this project is to support
multiple backend storage projects, would not it be better
to host the project in the github repository associated
with nbd [5]? Doing it that way could provide a more
neutral (as perceived by users) venue for hosting
nbd-runner and help you in getting more adoption for your
work.
This is a good idea, I will try to push this forward.
Thanks very much Vijay.
BRs
Xiubo Li
|
