Hacker News new | ask | show | jobs
by alerighi 1388 days ago
Awesome, to me it seems terrible, and something that can break anytime. You have two layers of translation, the actual FUSE filesystem implementation that uses the FUSE API to communicate with something that emulates a FUSE API in userspace to then talk via NFS to the kernel. NFS is broken in a lot of ways, especially with file locking, that could result in deadlocks.

Really FUSE should be implemented in the kernel itself, it was meant to do so, a kernel-side layer to allow implementing a filesystem userspace efficiently. When they created fuse NFS already existed, and if they decided to create a new protocol and add it to the kernel, rather that something on top of NFS or directly exposing a NFS server in applications, a reason maybe existed right?

Not having a stable FUSE implementation is one of the many reasons that made me abandon macOS and return to the combination of Windows and Linux. Even Windows has a mostly decent open-source FUSE implementation!

2 comments

NFS4 is broken in fewer ways FUSE is, and it has the advantage of being standardised and implemented by everything. The natural way forward would be to get rid of FUSE in this stack, not NFS4.
Well I don't see how FUSE is broken, while NFS surely is (it happened to me that I had processes that were in a state that was impossible to terminate without rebooting - this was because they did set locks in the NFS filesystem that they were never released, thus not allowing the processes PID to terminate and thus generating a slow resource leak in the kernel!)

Anyway, FUSE is more efficient, since the application directly talks to the kernel, without passing trough the TCP/IP stack and the NFS driver. It cannot be possibly implemented more efficiently without implementing the FS as a proper kernel module.

Also NFS introduces a security problem: authentication is tricky to implement, and I don't think it's used in this application: that allows any user on the computer to access, via the NFS API trough an userspace implementation the filesystem, bypassing any permission of the filesystem itself.

Finally NFS cannot support (as far as I know) all the features that are possible with a FUSE filesystem. And since it's based on a network protocol (meaning client and server may be on different machines with a non reliable network connecting them) something will probably never be supported/work reliably (for example inotify).

You’re right, a proper userspace filesystem implementation is the preferable route. I was mostly impressed by the neet hack.