Kernel mode drive usermode and not kernel mode > why?

[vkornilyev1988]

Hi, Why ? May I ask. Why was the new driver chosen to run in user mode rather than kernel mode? This limits its use to user mode only. Why can't you do the work in user mode and still have the ability to work with connections in the kernel, like nbd linux? After all, your first releases worked in the kernel. This is very important for me, since for corporate use ceph and nbd could be bootable for the system. And now it's cut it off. In principle, I would just like to understand whether corrections can be made to the old driver that works entirely in kernel mode for better performance, and then it will be just great! or add with the new driver the ability to connect a disk from the kernel as in the old driver, just like in Linux, example Linux: vmlinux nbd:xx:xx:xx:xx:port. To be able to boot from disk using all the new kernel features

[petrutlucian94]

The WNBD driver still runs in kernel mode. However, it's just a shim that forwards SCSI requests to userspace daemons such as the Ceph rbd-wnbd daemon or wnbd-client when acting as an NBD client.

The PR that moved the NBD client out of the driver describes the reasons for doing so: https://github.com/cloudbase/wnbd/pull/122.

About Ceph, at first we used NBD to map RBD images because:

• ceph already had an NBD daemon: https://github.com/ceph/ceph/tree/39e370099d014fc4b175e1f7fbc89c716d64e67f/src/tools/rbd_nbd
• NBD is a simple protocol so it was easy to implement a client
• there was no existing Windows NBD client, so we thought this might come handy for other use cases as well

At some point, we decided to implement another IO channel because of NBD limitations:

• quite slow - Winsock Kernel (WSK) is particularly slow on older Windows Server versions
• ksocket was crashing when initializing on older unsupported Windows releases
• doesn't expose all SCSI operations (we were interested in FUA or SCSI Persistent Reservations)

Having an entire Ceph RBD client implemented in kernel space was a no go for us since that implies duplicating the librbd functionality and would be very difficult to maintain, while having little to no benefits.

We really don't intend to move the NBD client back to the driver, the cons outweight the pros. If you absolutely need this, feel free to use an older WNBD version or even fork it.

[vkornilyev1988]

Hello. Yes, it is reasonable about what you wrote. Now it becomes clear. Thank you for the answer. Could you please tell me what kind of fork it is? Does the fork you are writing about exist?

[petrutlucian94]

Just a simple Github fork where you can add your custom patches, starting from a previous wnbd release that still had the NBD client as part of the driver.

[petrutlucian94]

I'll close this issue, let me know if you have any further questions.