What does HackerNews think of nfs-ganesha?

It's unfortunate that fuse-t follows the same closed source model as MacFUSE did. It's really holding things back.

I was hopeful that Ganesha NFS [1] would suffice as a bridge for the various FUSE filesystems I need to use with macOS, but alas, they have abandoned the FUSE interface and moved to FSAL/FSAL_VFS [2].

It would be really nice to have a clear path to building a copy of Ganesha NFS that supported a whole host of the great FUSE filesystems out there built to this API.

[1] https://github.com/nfs-ganesha/nfs-ganesha [2] https://github.com/nfs-ganesha/nfs-ganesha/issues/759

If it helps, as far as I'm aware Ganesha [1] is still widely used, supported, in some cases faster than the kernel implementation, and can be pointed at an arbitrary config file.

[1] https://github.com/nfs-ganesha/nfs-ganesha

This is used by the Ganesha project (userspace NFS server). Look for the symbol "container_of" and usages of it in https://github.com/nfs-ganesha/nfs-ganesha/ (disclaimer: I'm a minor contributor).

The way it's used is that Ganesha supports defining of alternate filesystem backends and serving them as NFS shares. Handles to objects (e.g. files) would exist as pointers which live inside the struct of the backend's handle struct. i.e.:

  struct my_file_data {
    struct ganesha_file_data {
      // generic data
    };

    // data specific to my module
  };

The "my" module would take pointers to ganesha_file_data when the NFS core code calls it. The "my" module then uses container_of to convert ganesha_file_data ptr to my_file_data ptr.