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?
Does that mean that all Fuse filesystems automatically gets this huge boost ?
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?