Say we want to implement memory mapping or some other feature that doesn’t map to NFS, well too bad because now everything has to be hacked in terms of NFS packets. Requiring FUSE to be underpinned by NFS further limits what our FUSE file systems can do. This creates a significant overhead over read & write syscalls that typically would have been extremely efficient with a kernel driver that can read/write process memory directly. This necessitates the generation, buffering, and parsing of TCP packets. KERNEL->NFS DRIVER->TCP SOCKET->FUSE NFS SERVER EMULATION->USER SPACE FILE SYSTEM Moving the FUSE driver into userspace is a hack at best and it looks like this: KERNEL->FUSE KERNEL DRIVER->USER SPACE FILE SYSTEM However barring an official apple implementation of FUSE, the next best thing would be a 3rd party kernel implementation as follows: Ideally there would be a direct path from the FUSE API to the kernel, maybe even one implemented by apple themselves. But now consider how FUSE itself needs to be implemented to hook up file systems into the OS. All FUSE file systems will be implemented in userspace using this API. The entire goal is to create a userspace API for file systems. Take a step back and think about what FUSE does in the first place. In this case it is clearly the better solution: this should not be in the kernel-space. Not the same functionality but actually faster, better support for file-locks and better stability.
0 Comments
Leave a Reply. |