Build, install on OS-X v10.10

[chadwickboggs]

Build fails when I attempt on OS-X v10.10, Darwin CO183LNETO63 14.5.0 Darwin Kernel Version 14.5.0: Wed Jul 29 02:26:53 PDT 2015; root:xnu-2782.40.9~1/RELEASE_X86_64 x86_64 i386 MacBookPro11,3 Darwin.

[trapexit]

Not having OSX myself nor having any output from your problem there isn't much I can do to help.

[darksin1]

I know this is old but I had the same problem and figured out how to make it work on OS-X v10.11.
I guess it'll be the same on v10.10.
I'm attaching the patch so you can try it out.
os-x_v10.11.patch.zip

[trapexit]

Thanks for the patch but scanning through this patch there looks to be a few problems.

• You can't replace eaccess with access. They behave differently. It needs to be an effective not actual user check. This would return false positives if mergerfs was run as root.
• I'm surprised OSX doesn't support standard POSIX *at functions like utimensat. That's annoying but not a real problem unless the alternative behaves differently. Same for the posix_f{advise,allocate}.
• What version of llvm does OSX use? I compile with clang++-3.6 on my linux machine without problems.
• Embedding linux/fs.h is not a preferred solution.

[darksin1]

• I just couldn't find a replacement for eaccess. I agree that's a problem when running as root, meanwhile I'm running it as an unprivileged user.
• I'm also surprised, although the documentation from linux and os x seems to agree in the behaviour.
• clang --version reports this: Apple LLVM version 7.3.0 (clang-703.0.29) Target: x86_64-apple-darwin15.3.0 Thread model: posix
• I know is an ugly hack, but linux/fs.h only exists in linux, and what is used from it are just constants as far as I saw.

I think a more general solution, from the portability perspective, is to use gnulib, but in my first attempt I ran into even more trouble.

[xinush]

Hi, thanks for the initial works for osx.

I have a quick question about the license issue. While the gnulib may be used to support some of missing functions in osx, it may likely require GPL/LGPL. Probably more restrictive than the current mergerfs license, if I am not too wrong.

I am wondering if you could possibly consider GPL at least for mac version w/ gnulib?

thanks!

[trapexit]

Only if for some reason the problem could only be fixed by embedding gnulib code but given the issues we've run into it seems extremely unlikely that's the case.

[xinush]

Thanks for the reply.

It seems two major issues are eaccess and utimensat if mergerfs needs to be ported beyond darksin1's initial conversion for osx, in order to closely match the original capability. While those may be rewritten/wrapped by own implementations, probably it has more to do with time/complexity to work with, and current availability to use at the moment.

As a user, I personally prefer to mergerfs over mhddfs while both are excellent tools. For a mac, only mhddfs was available (even as a package) until darksin1's patch was released. While the patch was great enough for my use case, it could be also nice with other capability as well.

Anyway, thanks for the great tool and patch. I guess I can probably put the additional patch to github that you can take a look.

many thanks!

[trapexit]

There are a few things more that need to be done to make it really usable on macOS. I've looked into them and they shouldn't be difficult to implement. eaccess can be replaced by faccessat it looks like and utimensat can be simulated. gnulib can't be used because mergerfs is doing hacky things to improve performance on Linux and if those things aren't simulated on macOS it's performance will be limited. AFAICT I should be able to do that but I need access to an macOS machine (recently done) and familiarize myself with the dev environment) to really test it out. The documentation is rather lacking for me to blindly patch it.

[xinush]

Hi,

Some osx patch version w/o gnulib has been uploaded to the cloned repository, in case it can help or save your time in any means. It includes the darksin1's patch and other additions. It also includes faccessat that you mentioned earlier (although it seems you already patched :-)

While I am not sure if you meant your performance optimizations, like preallocations or read ahead, or something else, personally, I have been using gnulib-based patch for the past few months without much noticeable issues (The performance was not the primary issue for my case as bottleneck was at other places though).

Anyway, thanks for your follow-ups and hard works!

Cheers!

[trapexit]

I already know what needs to be done I simply need an OSX machine to test
and build. The patch provided on this thread has a few issues as mentioned
above and I'd rather not release a version that's broken.

On Jul 31, 2016 8:58 AM, "xinush" notifications@github.com wrote:

Hi,

Some osx patch version w/o gnulib has been uploaded to the cloned
repository, in case it can help or save your time in any means. It includes
the darksin1's patch and other additions. It also includes faccessat that
you mentioned earlier (although it seems you already patched :-)

While I am not sure if you meant your performance optimizations, like
preallocations or read ahead, or something else, personally, I have been
using gnulib-based patch for the past few months without much noticeable
issues (The performance was not the primary issue for my case as bottleneck
was at other places though).

Anyway, thanks for your follow-ups and hard works!

Cheers!

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#115 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAMELOWZuNyfxy5opoS9FNXovUfqpmtuks5qbJvkgaJpZM4F4cUh
.

[trapexit]

Could someone try building master on OSX? It's got several changes which should help building on OSX. Please email me any build errors. Thanks.

[ahknight]

Looking at master@af9a71f:

./tools/cppfind: cpp is the wrong tool. use "cc -E ${FUSE_CFLAGS} -" instead. The final dash to use stdin is required.

The stat structure is different on OS X. The following are repeated often:

error: no member named 'st_atim' in 'stat'
error: no member named 'st_mtim' in 'stat'

Instead, OS X uses a timespec struct for times:

      struct timespec st_atimespec;  /* time of last access */
      struct timespec st_mtimespec;  /* time of last data modification */
      struct timespec st_ctimespec;  /* time of last file status change */

This looks like this:

struct timespec {
    long tv_sec;
    long tv_nsec;
};

Finally:

src/fs_base_utime_generic.hpp:273:16: error: no member named 'futimesat' in the global namespace

Mac OS doesn't have that GNU function but it does have futimes(2).

int futimes(int fildes, const struct timeval times[2]);

[ahknight]

After fixing those:

• ./src/fs_fallocate_osx.icpp: fallocate moved to unistd.h.
• Type size differences (dev_t is 32 bits; needs to be in a 64 bit container before the shift):

src/fs_inode.hpp:37:31: warning: shift count >= width of type [-Wshift-count-overflow]
      st.st_ino |= (st.st_dev << 32);

• Type differences:

src/gidcache.cpp:112:43: error: cannot initialize a parameter of type 'int *' with an lvalue of type 'gid_t [32]'
      rv = ::getgrouplist(pwd.pw_name,gid,rec->gids,&rec->size);

• xattr differences (system header is sys/xattr.h and includes an arg for position; FUSE mirrors this arg)

I'll draft up a patch for all this.

[trapexit]

• For futimesat: Yeah.... utimensat is the more appropriate call which IIRC was only available in macOS 10.10?
• dev_t size: I noticed it's also 32bit on older linux machines. I've been meaning to fix that. It's not a big issue in practice but I'll fix it.
• One thing that should be done for an OSX release is to use pthread_setugid_np and create a ugid_osx.hpp implementation so locking isn't a contention point. Practically speaking it probably wouldn't be but it'd be a nice to have.

Thanks for looking into this. I've just not had access to a machine to try porting it.

[ahknight]

I don't think futimesat is in there at all these days. Running Sierra:

$ grep -ri futimesat /usr/include
/usr/include/bsm/audit_kevents.h:#define	AUE_FUTIMESAT		285

Probably not what you're after. 🙂

If it was in there, it likely went away with gcc/glibc when llvm came to town.

[ahknight]

That said, I faked a version with fcntl and F_GETPATH. 🙂 I'll try to get a patch up tonight. I'm not sure I'll have it organized like the rest of the xplat code you have, but at least it'll compile/work and you can move things around the way you like.

[iFloris]

What are the chances this will be explored further @trapexit ? I have been lurking on this issue pretty much since it was opened and was very excited to see all the progress around this that you and @ahknight were making, though the code-technical finesses elude me.

[trapexit]

I have access to an macOS machine now but need to fix it up and get familiar with development on the platform before I can properly support it.

Recently I've made significant changes to mergerfs with regard to using libfuse. I now have it embedded into the project to have more control but this probably will complicate things on the macOS side.

[iFloris]

Thanks for your reply @trapexit 😄 I patiently albeit eagerly await any and all future developments!

[jkt628]

just tried 10.13.6 High Sierra and get

make[2]: Entering directory '/Users/thomasso/go/src/github.com/trapexit/mergerfs/libfuse/lib'
  CC       fuse.lo
In file included from fuse.c:19:
../include/fuse_compat.h:69:10: fatal error: 'sys/statfs.h' file not found
#include <sys/statfs.h>
         ^~~~~~~~~~~~~~
1 error generated.
make[2]: *** [Makefile:533: fuse.lo] Error 1

[ghost]

@jkt628 this is because, for some reason, configure doesn't properly #define __FreeBSD__; if you hack that into the top of fuse_compat.h it gets past this. In then will get stuck on:

../include/fuse_kernel.h:91:10: fatal error: 'linux/types.h' file not found
#include <linux/types.h>

which is a harder problem because the build explicitly assumes that the build environment is Linux.

[trapexit]

Because FUSE and libfuse were designed as a linux only. mergerfs has been patched to allow for using the system libfuse which may help on BSD based systems but other changes will still need to done regarding xattrs and possibly some fs calls that aren't cross platform.

[ghost]

FUSE may initially have been built on Linux; it's been available for OSX for a while -- it's even gone through a couple of evolutions (MacFUSE, and now OSXFuse). That said, I'm sure that there's not much help provided for building cross-platform clients. ext2fuse is probably a rich source of information about mapping Linux entities to BSD, but it's a Ruby client so probably not much help.

Anyway, I saw your earlier comment that you don't have a Mac; I was providing a resource for other Mac users that getting this working on OSX is not trivial.

I am curious -- fuse_compat.h specifically has #ifdefs for __FreeBSD__, and does the right thing and compiles correctly on OSX -- that file understands OSX. I'm interested why that file has code to work on OSX, but the surrounding build system doesn't. Was the file copied from the upstream FUSE project?

[trapexit]

I understand the general concept is available on other platforms and even called the same but the features, protocol, and userland aren't all the same or necessarily compatible. libfuse is not generally designed to be cross platform. Some efforts have been made but it's not a core focus.

Yes, it's from upstream. The whole fuse directory is just a vendored version of libfuse to help with stability given older versions on old distributions were buggy.

Being compatible with FreeBSD is not the same as OSX. OSX has different signatures for xattr functions and I believe the underlying protocol is slightly different.

[Danilo-Araujo-Silva]

@trapexit, maybe we could use Travis to check the build for MacOS (and we already have Catalina, 10.15.7, there).

https://docs.travis-ci.com/user/reference/osx/

At this project of mine I'm using it:

https://github.com/funttastic/universal_kotlin/blob/master/.travis.yml

Crossing fingers to have something for OSX ;)

Thanks for the good work!

[trapexit]

That doesn't help port mergerfs macos which would be a big'ish undertaking as it lo longer uses the standard high level API.