[Gluster-users] [Gluster-devel] Network Block device (NBD) on top of glusterfs
pkalever at redhat.com
Thu Mar 21 10:09:06 UTC 2019
On Thu, Mar 21, 2019 at 9:00 AM Xiubo Li <xiubli at redhat.com> wrote:
> I am one of the contributor for gluster-block
> <https://github.com/gluster/gluster-block> project, and also I
> contribute to linux kernel and open-iscsi <https://github.com/open-iscsi>
> 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
> <https://github.com/gluster/glusterfs/issues/633>, and good news is I
> have a working code, with most basic things @ nbd-runner project
> While this email is about announcing the project, and asking for more
> collaboration, I would also like to discuss more about the placement of the
> project itself. Currently nbd-runner project is expected to be shared by
> our friends at Ceph project too, to provide NBD driver for Ceph. I have
> personally worked with some of them closely while contributing to
> open-iSCSI project, and we would like to take this project to great success.
> Now few questions:
> 1. Can I continue to use http://github.com/gluster/nbd-runner as home
> for this project, even if its shared by other filesystem projects?
> - I personally am fine with this.
> 1. Should there be a separate organization for this repo?
> - While it may make sense in future, for now, I am not planning to
> start any new thing?
> It would be great if we have some consensus on this soon as nbd-runner is
> a new repository. If there are no concerns, I will continue to contribute
> to the existing repository.
Thanks Xiubo Li, for finally sending this email out. Since this email is
out on gluster mailing list, I would like to take a stand from gluster
community point of view *only* and share my views.
My honest answer is "If we want to maintain this within gluster org, then
80% of the effort is common/duplicate of what we did all these days with
* rpc/socket code
* cli/daemon parser/helper logics
* gfapi util functions
* logger framework
* inotify & dyn-config threads
* docsAboutGluster and etc ..
The repository gluster-block is actually a home for all the block related
stuff within gluster and its designed to accommodate alike functionalities,
if I was you I would have simply copied nbd-runner.c into
https://github.com/gluster/gluster-block/tree/master/daemon/ just like ceph
plays it here
Advantages of keeping nbd client within gluster-block:
-> No worry about maintenance code burdon
-> No worry about monitoring a new component
-> shipping packages to fedora/centos/rhel is handled
-> This helps improve and stabilize the current gluster-block framework
-> We can build a common CI
-> We can use reuse common test framework and etc ..
If you have an impression that gluster-block is for management, then I
would really want to correct you at this point.
Some of my near future plans for gluster-block:
* Allow exporting blocks with FUSE access via fileIO backstore to improve
large-file workloads, draft:
* Accommodate kernel loopback handling for local only applications
* The same way we can accommodate nbd app/client, and IMHO this effort
shouldn't take 1 or 2 days to get it merged with in gluster-block and ready
for a go release.
Hope that clarifies it.
> Xiubo Li (@lxbsz)
>  - https://github.com/gluster/gluster-block
>  - https://github.com/open-iscsi
>  - https://github.com/gluster/glusterfs/issues/633
>  - https://github.com/gluster/nbd-runner
> Gluster-devel mailing list
> Gluster-devel at gluster.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gluster-users