Live data from Hacker News

FUSE-T is a kext-less implementation of FUSE for macOS that uses NFSv4

github.com

21–30 of 73 posts

Re: FUSE-T is a kext-less implementation of FUSE for macOS that uses NFSv4

#21

It’s surprising that given Apple’s war on kexts, they still haven’t come out with a proper API for implementing local user-space filesystems. It seems like this exists for remote filesystems (eg: Google Drive, Dropbox), but not for filesystems on local storage devices? This sounds like a nice workaround, though!

Yes, an Apple-supported API is likely coming. They’ve been gradually providing userspace alternatives for kernel extensions. Their API isn’t likely to be FUSE but hopefully the community will develop a translation layer. I wonder if one of the holdups is that they don’t want a profusion of filesystems and would prefer everyone use ExFAT or APFS. Data loss/corruption ultimately results in more support calls and headac…

It’s been coming for so long that I lost hope.

Re: FUSE-T is a kext-less implementation of FUSE for macOS that uses NFSv4

#22
post #19

It’s surprising that given Apple’s war on kexts, they still haven’t come out with a proper API for implementing local user-space filesystems. It seems like this exists for remote filesystems (eg: Google Drive, Dropbox), but not for filesystems on local storage devices? This sounds like a nice workaround, though!

I wish everyone would just standardize on 9p already. It's solid and has existed for going on thirty years. Microsoft actually uses it for WSL, but afaik does provide the ability to access other 9p servers.

9p involves a lot of round trips to create/write files. I benchmarked sshfs using fuse vs. 9p in the kernel and sshfs was significantly faster.

Re: FUSE-T is a kext-less implementation of FUSE for macOS that uses NFSv4

#23

It’s surprising that given Apple’s war on kexts, they still haven’t come out with a proper API for implementing local user-space filesystems. It seems like this exists for remote filesystems (eg: Google Drive, Dropbox), but not for filesystems on local storage devices? This sounds like a nice workaround, though!

Yes, an Apple-supported API is likely coming. They’ve been gradually providing userspace alternatives for kernel extensions. Their API isn’t likely to be FUSE but hopefully the community will develop a translation layer. I wonder if one of the holdups is that they don’t want a profusion of filesystems and would prefer everyone use ExFAT or APFS. Data loss/corruption ultimately results in more support calls and headac…

Apple started replacing their own file system (and networking) kexts with user-mode file systems in macOS 13. Right now its locked up behind some private entitlements though. Hopefully they open it up more in the future.

For a quick overview check out a blog post on threedots. https://threedots.ovh/blog/2022/06/quick-look-at-user-mode-f...

Re: FUSE-T is a kext-less implementation of FUSE for macOS that uses NFSv4

#24

What prevents Apple from just integrating MacFUSE(or a reimplementation) into the their kernel, and then shipping it with the next release?

Isn’t Fuse itself LGPL? Thats perhaps one reason since copyleft licenses aren’t favourable from their view.

I would really love any equivalent API though as dealing with Perforce is a pain in the butt sometimes, and what Microsoft have done with the Prrforce Virtual File system is amazing.

Re: FUSE-T is a kext-less implementation of FUSE for macOS that uses NFSv4

#25

Earlier quoted context omitted.

Yes, an Apple-supported API is likely coming. They’ve been gradually providing userspace alternatives for kernel extensions. Their API isn’t likely to be FUSE but hopefully the community will develop a translation layer. I wonder if one of the holdups is that they don’t want a profusion of filesystems and would prefer everyone use ExFAT or APFS. Data loss/corruption ultimately results in more support calls and headac…

Apple started replacing their own file system (and networking) kexts with user-mode file systems in macOS 13. Right now its locked up behind some private entitlements though. Hopefully they open it up more in the future. For a quick overview check out a blog post on threedots. https://threedots.ovh/blog/2022/06/quick-look-at-user-mode-f...

It’s certainly been interesting watching the multi-decade arc play out. With Mach as the origins, everything other than tasks (processes) schedule and virtual mem was out of kernel and done over Mach port comms. Then xnu via next step and later OS X linked much more in kernel and exposed specific data types using com+ in iokit. And now more and more is moving back out of the kernel.

io_urging networking on Linux is another similar move out to use space

Re: FUSE-T is a kext-less implementation of FUSE for macOS that uses NFSv4

#26
While using network communications is a great workaround for platforms that don't natively support user-mode filesystems, you end up with a bottleneck of data being copied a bunch of times, plus the latency overhead of waking up a thread to accept a new network connection.

Re: FUSE-T is a kext-less implementation of FUSE for macOS that uses NFSv4

#27
post #8

Earlier quoted context omitted.

Weird that early in the issue comments the author claims they're going to release source for fuse-t, but then later in the comments changes course and says it's proprietary. Sounds like they originally wanted to release it as open source, but under a restrictive non-commercial license (which is fine, I guess), but then has gone back on that promise. I'm not gonna be one of those "proprietary software is immoral" peop…

Especially something like FUSE where it’s potentially the middle man of personal data. If there’s concern about other companies profiteering, release it under a license that prevents such and those companies can pay to license under something else. This approach could even be useful on Linux where fuse isn’t viable (e.g inside containers)

> This approach could even be useful on Linux where fuse isn’t viable (e.g inside containers)

By viable do you mean secure? You can definitely use FUSE within containers, but you do have to cap-add SYS_ADMIN.

Re: FUSE-T is a kext-less implementation of FUSE for macOS that uses NFSv4

#28

It’s surprising that given Apple’s war on kexts, they still haven’t come out with a proper API for implementing local user-space filesystems. It seems like this exists for remote filesystems (eg: Google Drive, Dropbox), but not for filesystems on local storage devices? This sounds like a nice workaround, though!

The point is that the userspace shoukdnt need a kext.

Re: FUSE-T is a kext-less implementation of FUSE for macOS that uses NFSv4

#29

Earlier quoted context omitted.

Apple started replacing their own file system (and networking) kexts with user-mode file systems in macOS 13. Right now its locked up behind some private entitlements though. Hopefully they open it up more in the future. For a quick overview check out a blog post on threedots. https://threedots.ovh/blog/2022/06/quick-look-at-user-mode-f...

It’s certainly been interesting watching the multi-decade arc play out. With Mach as the origins, everything other than tasks (processes) schedule and virtual mem was out of kernel and done over Mach port comms. Then xnu via next step and later OS X linked much more in kernel and exposed specific data types using com+ in iokit. And now more and more is moving back out of the kernel. io_urging networking on Linux is a…

Its my favorite part of watching the mac evolve. The man hours that has been used in the development is staggering.

Re: FUSE-T is a kext-less implementation of FUSE for macOS that uses NFSv4

#30

It’s surprising that given Apple’s war on kexts, they still haven’t come out with a proper API for implementing local user-space filesystems. It seems like this exists for remote filesystems (eg: Google Drive, Dropbox), but not for filesystems on local storage devices? This sounds like a nice workaround, though!

My personal desperate hope/wish is some insurance that iSCSI will continue to work and be somewhat performant, either via an API to deal with the kexts or better yet Apple buying Xtend SAN or developing their own and offering first party support. I'm worried though it's not going to make the cut :(
Post reply on HN