ExtFUSE: Making FUSE File-Systems Faster With eBPF

[phoronix]

Phoronix: ExtFUSE: Making FUSE File-Systems Faster With eBPF

Georgia Tech tends to be home to a lot of interesting open-source projects and incubating long-term FLOSS/Linux developers. This university's latest interesting open-source project is "ExtFUSE" for making user-space FUSE file-systems faster by making use of the in-kernel eBPF framework...

http://www.phoronix.com/scan.php?page=news_item&px=ExtFUSE-Faster-FUSE-eBPF

[mzs.112000]

Is this fully compatible with normal FUSE modules? If so, it could be a boon for performance on certain file systems... Or old computers...

[theriddick]

Hmmm, does this mean possible improvements for NTFS partitions under Linux also? they are lagging behind Windows performance a fair bit, even with big_writes flag.

[Lanz]

Stuff like copying over SSH via SSHFS/FUSE can bring a 64 bit system to its knees - GUI lockups waiting for a laggy file system to respond. More work is required.

[Weasel]

Stuff like copying over SSH via SSHFS/FUSE can bring a 64 bit system to its knees - GUI lockups waiting for a laggy file system to respond. More work is required.

Yeah you need at least a 1024-bit system for it to work at acceptable speed.

[ermo]

Who would have thought -- eBPF might make it more feasible for Linux to go from monolithic to a more hybrid micro-kernel/monolithic approach where the overhead is smaller than going full micro-kernel. Between this and the Gasket Google effort, maybe more effort will be put into shrinking the kernel (and hence its attack surface?) by punting stuff that doesn't strictly *need* to be in the kernel to userspace.

But what do I know, I'm just thinking out loud here...

[oiaohm]

Who would have thought -- eBPF might make it more feasible for Linux to go from monolithic to a more hybrid micro-kernel/monolithic approach where the overhead is smaller than going full micro-kernel. Between this and the Gasket Google effort, maybe more effort will be put into shrinking the kernel (and hence its attack surface?) by punting stuff that doesn't strictly *need* to be in the kernel to userspace.

But what do I know, I'm just thinking out loud here...

https://lwn.net/Articles/755919/

Really Linux kernel has not be pure monolithic for quite some time. Usermode helpers have been around for quite some time allowing the kernel to have particular tasks performed outside kernel space. Bpfilter is working on having the usermode helper embedded inside the .ko module.

I do agree that Linus had it right that pure user mode file systems are a toy because they will always be badly performing. eBPF allows you to get some kernel space code while not being dependant on the exact kernel. JIT that eBPF has basically turns BPF passed to kernel into native executable code after being validated.

[ermo]

https://lwn.net/Articles/755919/

Really Linux kernel has not be pure monolithic for quite some time. Usermode helpers have been around for quite some time allowing the kernel to have particular tasks performed outside kernel space. Bpfilter is working on having the usermode helper embedded inside the .ko module.

I do agree that Linus had it right that pure user mode file systems are a toy because they will always be badly performing. eBPF allows you to get some kernel space code while not being dependant on the exact kernel. JIT that eBPF has basically turns BPF passed to kernel into native executable code after being validated.

Thanks for the link -- I hadn't seen it before now. It's an interesting concept to be sure.

[Mystro256]

Stuff like copying over SSH via SSHFS/FUSE can bring a 64 bit system to its knees - GUI lockups waiting for a laggy file system to respond. More work is required.

Why not just use scp? I use SSHFS over FUSE for small stuff, but I find it's worth pulling out a terminal for the big/batch stuff.