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

61–70 of 73 posts

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

#61

Post by lxgr »

xoa wrote: post #30
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!

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 :(

Isn't it already gone from the most recent macOS releases? Or do you mean Apple providing an API that allows implementing a performant non-kext third party initiator?

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

#62

Post by lxgr »

mathiasgredal wrote: post #10

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

They already have something like this, it's just not a public API and only used for their own FAT and NTFS implementations: 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

#63

Post by Conan_Kudo »

flakes wrote: post #27
PlutoIsAPlanet wrote: post #12

Earlier quoted context omitted.

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.

Unprivileged FUSE has been a thing for a while now: https://zameermanji.com/blog/2022/8/5/using-fuse-without-roo...

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

#64

Post by butterisgood »

murderfs wrote: post #41
donatj wrote: post #40

Earlier quoted context omitted.

It's a network protocol as far as everything from Plan9 was designed to be able to operate over the network in the late 90s sense of " the network is the computer". The local file system of Plan 9 though is exposed locally through 9p

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.

Don't talk about yourself in such ways. I'm sure you had something to contribute to the world before you made this comment.

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

#65

Post by crest »

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!

The have the file provider (https://developer.apple.com/documentation/fileprovider/) API. It works by caching the remote files in a system managed cache in APFS. The idea is sound for for Dropbox, GDrive etc, but not a full replacement for FUSE. The nice thing is that it can keep the files locally pre-cached and replicate local changes asynchronously.

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

#67

Post by blackpanda467 »

PlutoIsAPlanet wrote: post #2

Why is there a GitHub and no source code?

From the author: right now fuse-t cannot be made open sourced because it won't play nice with existing contracts. You can try my other project which is open source and can be an alternative to fuse: https://github.com/macos-fuse-t/go-smb2

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

#68

Post by the8472 »

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…

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

io_uring. and a virtual filesystem may have to serve multiple concurrent requests from several threads. so even if individual IO calls are blocking in the aggregate they still have to be interleaved.

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

#69

Post by rgovostes »

HHad3 wrote: post #58
macshome wrote: post #23

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

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 appe…

Thanks. I was aware of FAT being the first filesystem in userspace (maybe for iOS devices to mount SD cards?) but did not know it was open source or that FSKit existed. Maybe an enterprising hacker could dump the Obj-C header from that framework and start writing a FUSE translation layer.

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

#70

Post by mbirth »

dmitrygr wrote: post #54
mbirth wrote: post #45

Earlier quoted context omitted.

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.

For Python programs, a mere

FUSE_LIBRARY_PATH=/usr/local/lib/libfuse-t.dylib

is sufficient. For other binaries, overwriting the libfuse*.dylib with the libfuse-t.dylib should work in the same way.

Post reply on HN