In the beginning, only privileged ones will be allowed to run in pass-through mode. But goal/roadmap calls for all FUSE filesystems eventually to have this near-native performance.
I feel I should know this in my bones after so many years, but does ‘privileged’ in kernel context also include ‘sudo/sudo su’ elevated users ? I wonder if the kernel distinguish between pure root, and elevated user …or if it even matters here ?
Anyway, this is cool. There’s a ton of crazy file systems that just didn’t pan out bc of speed issues. I’ll just leave these links to filesystems.
How would the update affect stuff like a GoCryptFS volume which I mount and use periodically but not all the time? Would those files be processed much faster than previously?
In the beginning, only privileged ones will be allowed to run in pass-through mode. But goal/roadmap calls for all FUSE filesystems eventually to have this near-native performance.
I feel I should know this in my bones after so many years, but does ‘privileged’ in kernel context also include ‘sudo/sudo su’ elevated users ? I wonder if the kernel distinguish between pure root, and elevated user …or if it even matters here ?
Anyway, this is cool. There’s a ton of crazy file systems that just didn’t pan out bc of speed issues. I’ll just leave these links to filesystems.
https://github.com/libfuse/libfuse/wiki/Filesystems A ton of cool ideas!.. I need my AI to have access via fuse. https://en.wikipedia.org/wiki/Filesystem_in_Userspace?lang=en less crazy systems but probably stable projects
Thanks for sharing the info!
sudo allows so run actions as root, so I would say yes.
But a privileged filesystem might not be invoked by the user, it may be a process running as root.
How would the update affect stuff like a GoCryptFS volume which I mount and use periodically but not all the time? Would those files be processed much faster than previously?