Hi, I have been trying to build NFS-Ganesha on macOS, and having a bit of trouble - there are quite a lot of compiler errors. But I also noticed someone has at least tried in the past, as I've seen some `#ifdef __APPLE__` lines here and there. Is macOS compatibility on anyone's radar? Did it once build in the past? Thank you, Matt
I have been trying to build NFS-Ganesha on macOS, and having a bit of trouble - there are quite a lot of compiler errors. But I also noticed someone has at least tried in the past, as I've seen some `#ifdef __APPLE__` lines here and there. Is macOS compatibility on anyone's radar? Did it once build in the past?
There has never been a concerted effort to make nfs-ganesha work on MacOS. The FreeBSD work (which may not function any more) may be of some help. In order to use FSAL_VFS, Ganesha does rely on a kernel ability to open files by handle which may or may not exist on MacOS, it also relies on being able to set credentials (fsuid, fsgid, group list) per thread. Oh, and byte range locks won't work without porting Open File Description Locks. I'm sure there are other catches. FSALs for library file systems (Gluster, Ceph, and RGW) are more likely to be workable since they don't rely on Linux specific kernel extensions beyond POSIX. Frank
Thank you for the response. Fortunately I don't think I need FSAL_VFS. My goal is to create an in-memory filesystem in order to benchmark macOS's NFS client. I essentially want to create a more specialized FSAL_MEM. If I understand the NFS-Ganesha architecture properly, FSAL_VFS is not needed since I don't care about a concrete POSIX filesystem. Here are a few things I'm hacking around to get things building, and I hope to have some results in the next few days: - The Apple "ld" doesn't support --version-script=, so it must be switched to use -exported_symbols_list - The build system assumes the URCU library header files are in the search path by default, which is not the case with homebrew. - We must use EPOLL emulation (using kqueue) which was originally written for FreeBSD - I changed several #include lines from <gssapi/foo.h> to <GSS/foo.h> to get around compiler errors though I'm not sure if this actually solved anything :) - Redefining of strlcpy and strnlen - Some atomic_fetch_* functions are not defined properly
Matt, are you looking to use Ganesha on Mac for production, or are you using it as a development platform? I almost had Ganesha compiling on MacOSX a while back, but only to use as a developer platform: I wanted to be able to code on planes, as I (used to) fly a lot of 12h+ long haul flights. Then I discovered that Docker containers are a great way (and it's free!) to run a full Linux environment on a Mac. Just build your own docker container with developer tools and dependencies. On Tue, Sep 1, 2020 at 10:22 AM <matvore@comcast.net> wrote:
Thank you for the response.
Fortunately I don't think I need FSAL_VFS. My goal is to create an in-memory filesystem in order to benchmark macOS's NFS client. I essentially want to create a more specialized FSAL_MEM. If I understand the NFS-Ganesha architecture properly, FSAL_VFS is not needed since I don't care about a concrete POSIX filesystem.
Here are a few things I'm hacking around to get things building, and I hope to have some results in the next few days: - The Apple "ld" doesn't support --version-script=, so it must be switched to use -exported_symbols_list - The build system assumes the URCU library header files are in the search path by default, which is not the case with homebrew. - We must use EPOLL emulation (using kqueue) which was originally written for FreeBSD - I changed several #include lines from <gssapi/foo.h> to <GSS/foo.h> to get around compiler errors though I'm not sure if this actually solved anything :) - Redefining of strlcpy and strnlen - Some atomic_fetch_* functions are not defined properly _______________________________________________ Devel mailing list -- devel@lists.nfs-ganesha.org To unsubscribe send an email to devel-leave@lists.nfs-ganesha.org
On Tue, Sep 01, 2020 at 10:33:59AM +1000, Bjorn Leffler wrote:
Matt, are you looking to use Ganesha on Mac for production, or are you using it as a development platform?
I almost had Ganesha compiling on MacOSX a while back, but only to use as a developer platform: I wanted to be able to code on planes, as I (used to) fly a lot of 12h+ long haul flights. Then I discovered that Docker containers are a great way (and it's free!) to run a full Linux environment on a Mac. Just build your own docker container with developer tools and dependencies.
Running this in a Linux container may add additional noise to the measurement - I want to benchmark the NFS server running on loopback in particular. So yes, this is not purely for development. I am doing a similar benchmark with macOS's SMB client using Samba. I plan to use whichever protocol+OSS server pair performs better, assuming there is a significant difference in performance.
Thank you for the response.
Fortunately I don't think I need FSAL_VFS. My goal is to create an in-memory filesystem in order to benchmark macOS's NFS client. I essentially want to create a more specialized FSAL_MEM. If I understand the NFS-Ganesha architecture properly, FSAL_VFS is not needed since I don't care about a concrete POSIX filesystem.
Here are a few things I'm hacking around to get things building, and I hope to have some results in the next few days: - The Apple "ld" doesn't support --version-script=, so it must be switched to use -exported_symbols_list - The build system assumes the URCU library header files are in the search path by default, which is not the case with homebrew. - We must use EPOLL emulation (using kqueue) which was originally written for FreeBSD - I changed several #include lines from <gssapi/foo.h> to <GSS/foo.h> to get around compiler errors though I'm not sure if this actually solved anything :) - Redefining of strlcpy and strnlen - Some atomic_fetch_* functions are not defined properly
Ok, if you just want to use FSAL_MEM you should have a much easier time. What changes do you want to make to it? It was developed to be able to test latency in the Ganesha stack without having to factor in latency of the back end filesystem, so if you have additional testing needs for it, let's talk about incorporating them. Once you get it working, can you commit to supporting it? None of us in the current active development community use Macs so our ability to keep it working will be limited. Frank
Good news: I was able to get a macOS build completed which included FSAL_MEM. It's still not actually serving successfully yet :) I am hitting a few memory access exceptions, some of which I've figured out, some of which I haven't. On Wed, Sep 02, 2020 at 11:02:30AM -0700, Frank Filz wrote:
Ok, if you just want to use FSAL_MEM you should have a much easier time. What changes do you want to make to it? It was developed to be able to test latency in the Ganesha stack without having to factor in latency of the back end filesystem, so if you have additional testing needs for it, let's talk about incorporating them.
I'm not sure how I'll change FSAL_MEM, if at all. It may not be required if I just make my own super-simple backend which mimics the benchmark backend I made in Samba.
Once you get it working, can you commit to supporting it? None of us in the current active development community use Macs so our ability to keep it working will be limited.
If I get it to work *and* decide to go forward using it in production, then I'll make that clear, commit to support it, and start upstreaming macOS-specific patches (actually I have an employer and my teammates will help support it). I do have a couple of patches that are related to building but probably generally valuable regardless of macOS support, so I'll send those in the coming days. Thanks, Matt
participants (4)
-
Bjorn Leffler -
Frank Filz -
Matthew DeVore -
matvore＠comcast.net