6 ms·

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

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!

rgovostes 3y ago
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 headaches for them, after all.
- tambourine_man 3y ago
  It’s been coming for so long that I lost hope.
- macshome 3y ago
  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-file-systems-on-macos-ventura/ https://threedots.ovh/blog/2022/06/quick-look-at-user-mode-f...
  - strangemonad 3y ago
    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
    - detourdog 3y ago
      Its my favorite part of watching the mac evolve. The man hours that has been used in the development is staggering.
  - HHad3 3y ago
    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/423d7fb56a080725daed182dfff8d854f6721414/msdos_appex/msdosFileSystem.m https://github.com/apple-oss-distributions/msdosfs/blob/423d...
    - rgovostes 3y ago
      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.
duped 3y ago
> 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 offerings. User space file systems (to them) are for remote storage. Users should use iCloud. Apps that can't shim over iCloud should be file provider extensions. If your app doesn't fit in those boxes then Apple doesn't care about providing the APIs to implement it cleanly on their platform. You can hack it through NFS. (0) https://developer.apple.com/documentation/fileprovider https://developer.apple.com/documentation/fileprovider
- comex 3y ago
  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 they did so they had to lose some functionality, like the ability to store data on an external drive [1]. And for the less popular use case of third-party filesystems that aren't just for syncing, File Provider is completely inapplicable. The box covers most of the use cases that most users are using third-party filesystems for. But it's shrink-wrapped around those use cases – no room to invent new ones. [1] https://talk.tidbits.com/t/dropbox-drops-support-for-storing-files-on-an-external-drive-and-onedrive-retains-it/20797 https://talk.tidbits.com/t/dropbox-drops-support-for-storing...
  - duped 3y ago
    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 hamstrung by the same design contraints of iCloud and APFS.
donatj 3y ago
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.
- vbitz 3y ago
  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.
  - donatj 3y ago
    Perfect is the enemy of good, and 9p is great.
    - speed_spread 3y ago
      That's not an argument here. If starting from scratch, might as well go with the thing that works best. Ssh is not an obscure protocol. If it's faster than 9p, that's what I'll use.
    - coldtea 3y ago
      Any rational reason you like it?
    - dmw_ng 3y ago
      That sound you hear is the hellish screeching of a million git status monorepo users waiting for their shell prompt to reappear
- the8472 3y ago
  9p is a network protocol. For machine local filesystems one can do better by making use of shared memory which fuse and virtio-fs do.
  - donatj 3y ago
    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
detourdog 3y ago
The point is that the userspace shoukdnt need a kext.
xoa 3y ago
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 :(
- lxgr 3y ago
  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?
inkyoto 3y ago
> […] Apple’s war on kexts Hardly a war, a rather rational decision it is – they are progressively moving kernel modules, drivers, file systems and network components into the user space. It is a foundational design principle of GNU Hurd where everything, apart from the microkernel server, runs in the user space. Minix 3 followed the same principle, and many other microkernel designs as well. It makes sense from the resilience point of view where a defective kernel module / driver can no longer crash the entire system. It also makes sense from the security perspective on – the kernel itself is cryptographically sealed off and can't be tampered with. Previously, the overhead of extra context switches was too high on the old CPU's and hardware, but today's computing devices are fast and the hardware is more optimised, so moving stuff into the user space is viable and incurs a much smaller performance penalty.
- mcpackieh 3y ago
  "War on __" doesn't imply an irrational war on __
  - iknowstuff 3y ago
    Only if you’re a stickler. It does assume an opponent and has a negative connotation
    - mcpackieh 3y ago
      [dead]
- viraptor 3y ago
  It makes sense if there's some replacement available. Less so, if there's none (unless you're Apple itself of course...)
crest 3y ago
The have the file provider (https://developer.apple.com/documentation/fileprovider/ 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.

rgovostes 3y ago

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 headaches for them, after all.

tambourine_man 3y ago
It’s been coming for so long that I lost hope.
macshome 3y ago
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-file-systems-on-macos-ventura/ https://threedots.ovh/blog/2022/06/quick-look-at-user-mode-f...
- strangemonad 3y ago
  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
  - detourdog 3y ago
    Its my favorite part of watching the mac evolve. The man hours that has been used in the development is staggering.
- HHad3 3y ago
  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/423d7fb56a080725daed182dfff8d854f6721414/msdos_appex/msdosFileSystem.m https://github.com/apple-oss-distributions/msdosfs/blob/423d...
  - rgovostes 3y ago
    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.

duped 3y ago

> 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 offerings. User space file systems (to them) are for remote storage. Users should use iCloud. Apps that can't shim over iCloud should be file provider extensions. If your app doesn't fit in those boxes then Apple doesn't care about providing the APIs to implement it cleanly on their platform. You can hack it through NFS. (0) https://developer.apple.com/documentation/fileprovider https://developer.apple.com/documentation/fileprovider

comex 3y ago
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 they did so they had to lose some functionality, like the ability to store data on an external drive [1]. And for the less popular use case of third-party filesystems that aren't just for syncing, File Provider is completely inapplicable. The box covers most of the use cases that most users are using third-party filesystems for. But it's shrink-wrapped around those use cases – no room to invent new ones. [1] https://talk.tidbits.com/t/dropbox-drops-support-for-storing-files-on-an-external-drive-and-onedrive-retains-it/20797 https://talk.tidbits.com/t/dropbox-drops-support-for-storing...
- duped 3y ago
  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 hamstrung by the same design contraints of iCloud and APFS.

donatj 3y ago

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.

vbitz 3y ago
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.
- donatj 3y ago
  Perfect is the enemy of good, and 9p is great.
  - speed_spread 3y ago
    That's not an argument here. If starting from scratch, might as well go with the thing that works best. Ssh is not an obscure protocol. If it's faster than 9p, that's what I'll use.
  - coldtea 3y ago
    Any rational reason you like it?
  - dmw_ng 3y ago
    That sound you hear is the hellish screeching of a million git status monorepo users waiting for their shell prompt to reappear
the8472 3y ago
9p is a network protocol. For machine local filesystems one can do better by making use of shared memory which fuse and virtio-fs do.
- donatj 3y ago
  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

detourdog 3y ago

The point is that the userspace shoukdnt need a kext.

xoa 3y ago

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

lxgr 3y ago
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?

inkyoto 3y ago

> […] Apple’s war on kexts Hardly a war, a rather rational decision it is – they are progressively moving kernel modules, drivers, file systems and network components into the user space. It is a foundational design principle of GNU Hurd where everything, apart from the microkernel server, runs in the user space. Minix 3 followed the same principle, and many other microkernel designs as well. It makes sense from the resilience point of view where a defective kernel module / driver can no longer crash the entire system. It also makes sense from the security perspective on – the kernel itself is cryptographically sealed off and can't be tampered with. Previously, the overhead of extra context switches was too high on the old CPU's and hardware, but today's computing devices are fast and the hardware is more optimised, so moving stuff into the user space is viable and incurs a much smaller performance penalty.

mcpackieh 3y ago
"War on __" doesn't imply an irrational war on __
- iknowstuff 3y ago
  Only if you’re a stickler. It does assume an opponent and has a negative connotation
  - mcpackieh 3y ago
    [dead]
viraptor 3y ago
It makes sense if there's some replacement available. Less so, if there's none (unless you're Apple itself of course...)

crest 3y ago

The have the file provider (https://developer.apple.com/documentation/fileprovider/ 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.