On Sunday, February 22nd, 2026 at 2:07 AM, Anthony D'Atri <aad@dreamsnake.net> wrote:

• For the native Ceph client (at https://github.com/ceph/wnbd), it seems like this code may work for some customers that don’t want to use NVMe-OF but this code is not currently maintained since the last update was three years ago.

Exactly.  There are some people who are using the Dokan bits successfully, others who are hesitant if it’s unmaintained.

• And lastly, is there some other role the respondents see for Windows that I haven’t included?
  

The client is I think the focus.  

It seems to me that unless there are shortcomings in either the Windows NVMe-OF initiator or the Ceph NVMe-OF target that the best way to support Windows clients is via NVMe-OF. What are the shortcomings that lead you toward putting effort into the native Ceph client for Windows?

The native client predates the Ceph NVMe gateway.  The latter is resource-intensive and acts as a translator.  A native RBD client is more efficient, less to manage on the Ceph side, and needs fewer resources. The NVMeoF gateway basically attaches RBD volumes and exports via the other protocol.  It replaces the older iSCSI GW that wasn’t great, and which is itself unmaintained.  

I see more interest in MS Windows CephFS client than RBD, ymmv.  

Good to know that the CephFS client may be more important to people than block layer.  TBH helping with a CephFS client seems much more interesting to me than yet another block client as the file system semantics are much richer.   

Regarding resources required on NVMe-OF gateway vs initiator : those costs are going to be paid on one side or the other (nothing profound there).  At least it's not stateless like iSCSI.  Clearly there are scenarios where it's best to have the resources dedicated at the gateway and then there are other scenarios where distributing the load out to the compute nodes scales better.   It's quite straight forward to have something like a smart NIC implement the NVMe-OF initiator in hardware on the compute side to have a very thin client on compute (although work needs to be done to not expose failures that today's smart NICs don't handle well up to the application or VM).  So one important question to me is: Do you want to implement a new block client to handle just the cases where the customer wants to have a thin gateway and more resource intense client side for block storage?  It may be important enough to warrant the extra work.  DPUs offer a good solution to offload a complex block client to but that is extremely vendor specific work.

Regarding CephFS client for Windows:  The complex part of a Windows network redirector is cache and memory manager integration.  It gets easier if you're not trying to host a page file on the remote disk but still quite tricky.  There are other considerations to take into account such as whether you want to limit it to a single transport like TCP or you also want to support things like RDMA or QUIC.  Given a quick look on the web, I'd say it looks like QUIC would be required but RDMA is more of a  "nice to have" feature since there are so many networking complexities. 

So a CephFS client on Windows sounds fun.  I'll pull down both the ceph-client and ceph-dokan repos to take a look.  

Was the intention of the original thread more focused on block or file?  Or more likely Windows Ceph integration in general.

-Andy