> By keeping the I/O path mostly within the kernel, we can dramatically > increase the speed of disk-based filesystems.
ZFS, BTRFS, and bcachefs all support compression, checksumming, and RAID. ZFS and bcachefs also support encryption, and f2fs and ext4 support fscrypt. Will this patchset be able to improve FUSE implementations of these filesystems? I'd rather not be in the situation where one can have a FUSE filesystem that is fast, but only if it doesn't support modern data integrity or security features. I'm not a filesystem developer, but here are some ideas (that you can take or leave): 1. Keep the compression, checksumming, and/or encryption in-kernel, and have userspace tell the kernel what algorithm and/or encryption key to use. These algorithms are generally well-known and secure against malicious input. It might be necessary to make an extra data copy, but ideally that copy could just stay within the CPU caches. 2. Somehow integrate with the blk-crypto framework. This has the advantage that it supports inline encryption hardware, which I suspect is needed for this to be usable on mobile devices. After all, the keys on these systems are often not even visible to the kernel, let alone to userspace. 3. Figure out a way to make a userspace data path fast enough. To prevent data corruption by unprivileged users of the FS, it's necessary to make a copy before checksumming, compression, or authenticated encryption. If this copy is done in the kernel, the server doesn't have to perform its own copy. By using large ring buffers, it might be possible to amortize the context switch cost away. Authenticated encryption also needs a copy in the *other* direction: if the (untrusted) client can see unauthenticated plaintext, it's a security vulnerability. That needs another copy from server buffers to client buffers, and the kernel can do that as well. 4. Make context switches much faster. L4-style IPC is incredibly fast, at least if one doesn't have to worry about Spectre. Unfortunately, nowadays one *does* need to worry about Spectre. Obviously, none of these will be as fast as doing DMA directly to user buffers. However, all of these features (except for encryption using inline encryption hardware) come at a performance penalty already. I just don't want a FUSE server to have to pay a much larger penalty than a kernel filesystem would. I'm CCing the bcachefs, BTRFS, and ZFS-on-Linux mailing lists. -- Sincerely, Demi Marie Obenour (she/her/hers)
OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
