Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

51–60 of 73 posts

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

#51

Post by dagmx »

arthur2e5 wrote: post #48
dagmx wrote: post #24

Earlier quoted context omitted.

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.

Macfuse itself has been closed source for a long time. Whether their EULA is compatible with the LGPL though, I don’t know. (Also, the old question: are APIs copyrightable?)

But do they bundle libfuse as a dylib? If they do, they’re probably in the right.

And API copyright aside, how would one prove it’s only API compatible and not using the implementation as well without also open sourcing their implementation?

It would almost be better to be similar but not the same. Then everyone else can just do subtle ifdef changes to their fuse code.

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

#52

Post by dmitrygr »

Sadly it is NOT a drop in replacement at all and requires recompilation of every app the uses MacFUSE. Thus, it is useful for precisely 0% of fuse-using macOS apps out there. There is a bug in veracrypt GitHub to make fuse-t an option. It has had no action since April.

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

#53

Post by pzmarzly »

tadfisher wrote: post #50
murderfs wrote: post #41

Earlier quoted context omitted.

Yeah, and that's one of the reasons plan9 was dogshit and never amounted to anything. "Everything is a file" is bad enough, "Everything is a file which might be 'transparently' across a network" is insane.

Classic blocking I/O is the problem, not network transparency. If you don't want files to be transparent through latency/throughput boundaries, then you should also disable the VFS cache.

Filesystem cache may make latency unpredictable, but it won't make open() unexpectedly fail with ECONNREFUSED. Most programs barely handle ENOENT, let alone EINTR.

Also, how do you do async fstat and mkdir in Linux? I don't see it in manpages.

AFAIK Plan9 answers to that was to not implement POSIX interfaces, and instead all I/O looked like RPC calls. This is generally a good design idea, but it's hard to sell an OS where all existing software will have to be rewritten for.

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

#54

Post by dmitrygr »

mbirth wrote: post #45
mynegation wrote: post #20

I upgraded my MBP after keeping MBP 2013 for 10 years and had to go through the shamanic dance of booting Sonoma into the safe mode, changing preferences and rebooting again to get macfuse working and I would still prefer it to dealing with NFS.

Fuse-T works as a drop-in replacement for the traditional FUSE. And pretty good I must say. You don’t notice the NFS part, it’s all handled by fuse-t itself.

No it doesn’t. Go try to get VeraCrypt to use it. It requires code changes and recompilation.

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

#55

Post by coldtea »

donatj wrote: post #37
vbitz wrote: post #22

Earlier quoted context omitted.

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.

Perfect is the enemy of good, and 9p is great.

Any rational reason you like it?

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

#56

Post by GoblinSlayer »

pzmarzly wrote: post #53
tadfisher wrote: post #50

Earlier quoted context omitted.

Classic blocking I/O is the problem, not network transparency. If you don't want files to be transparent through latency/throughput boundaries, then you should also disable the VFS cache.

Filesystem cache may make latency unpredictable, but it won't make open() unexpectedly fail with ECONNREFUSED. Most programs barely handle ENOENT, let alone EINTR. Also, how do you do async fstat and mkdir in Linux? I don't see it in manpages. AFAIK Plan9 answers to that was to not implement POSIX interfaces, and instead all I/O looked like RPC calls. This is generally a good design idea, but it's hard to sell an OS…

Conceptually it's possible: async fstat sets pending read, then epoll could return read flag when it completes, after that fstat completes without delay.

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

#57

Post by dmw_ng »

donatj wrote: post #37
vbitz wrote: post #22

Earlier quoted context omitted.

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.

Perfect is the enemy of good, and 9p is great.

That sound you hear is the hellish screeching of a million git status monorepo users waiting for their shell prompt to reappear

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

#58

Post by HHad3 »

macshome wrote: post #23
rgovostes wrote: post #11

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...

The linked msdos source code on GitHub has since been rewritten by Apple /again/ [1], so the article is a bit out of date. This happened 3 months ago, and it now plugs into a private framework named FSKit.

I did not immediately see any private entitlements that restrict access to this API, nor is msdos.fs signed with special entitlements on my machine. Chances are this API works for any filesystem by dropping an appex into /Library/Filesystems. Looking forward to this being documented and made public eventually.

[1] https://github.com/apple-oss-distributions/msdosfs/blob/423d...

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

#59

Post by lxgr »

duped wrote: post #15
Reason077 wrote: post #9

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!

> they still haven’t come out with a proper API for implementing local user-space filesystems. They have, it's called a File Provider Extension (0). The major downside is that it's extremely limited in what you can provide and it's an extension of the interface on top of APFS and not a proper file system in user space. Frankly, I don't think Apple cares about creating features that would interfere with their own offe…

File Provider is really an API optimized for "synchronizing file systems" (i.e. network file systems with an explicit local cache, e.g. something like Google Drive or Dropbox).

It doesn't seem like a great fit for either network file systems or local file systems: There's mandatory caching, which means everything remote accessed locally is written to disk at least once (completely useless and actively counterproductive for e.g. a local ext4 driver, which is something I dearly miss for fixing Raspberry PI root volumes), and I'm not sure if there's a way to implement remote file locks either.

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

#60

Post by lxgr »

duped wrote: post #33
comex wrote: post #17

Earlier quoted context omitted.

I'm not sure "interfere with their own offerings" is quite the right framing. It's more about "going beyond their imagined use case". iCloud Drive is a File Provider. Third-party services that want to do the same kind of file syncing as iCloud Drive, and thus compete it with it, can. And there are several highly-popular competitors that have recently moved to File Provider, like Dropbox and Google Drive. But when the…

My point is their view of a file provider is as a remote file storage API. This is one of the use cases of a file system in user space, but quite different from them generally. Most of the interesting use cases that FUSE covers are completely unsupported by the File Provider API. And I believe this is because they want anything that might be useful but competitive with the features they provide their users to be hams…

I'm not opposed to pointing fingers at Apple when it's justified, but I believe in this case it's really just a matter of priorities.

My guess is that the number of users that use remote file storage providers is just much larger than that of users using actual (non-SMB) network or local (non-(ex)FAT) file systems, so they created a kext replacement for that use case first.

If anything, the File Provider API levels the playing field between iCloud and third-party remote storage providers, since the neat APFS tricks they can use to implement it would otherwise be unavailable to third party developers. For example, I find Google Drive to be much more well-behaved on File Provider than it ever was when using FUSE (I blame it for some hangs or kernel panics) or SMB (which was more stable, but did not support Spotlight at all).

For all the other use cases, I'm hopeful that we'll be seeing a real macOS FUSE sooner rather than later.

Post reply on HN