11:47 p.m.
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
12:42 a.m.
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
7:22 p.m.
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
7:33 p.m.
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(a)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(a)lists.nfs-ganesha.org
To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org
7:23 p.m.
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.
1:02 p.m.
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
12:39 a.m.
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
1600
days inactive
1608
days old
6 comments
4 participants
participants (4)
-
Bjorn Leffler -
Frank Filz -
Matthew DeVore -
matvore＠comcast.net