It cannot be possibly implemented more efficiently without implementing the FS as a proper kernel module.Īlso 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.įinally NFS cannot support (as far as I know) all the features that are possible with a FUSE filesystem. 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!)Īnyway, FUSE is more efficient, since the application directly talks to the kernel, without passing trough the TCP/IP stack and the NFS driver. Every time the object is returned by LOOKUP, MKDIR, MKNOD, LINK, SYMLINK or CREATE, should their reference count be increased. Instead, they are identifiers of the inode in the kernel's inode cache. I think it's important to realise that a FUSE nodeid _does not_ represent an identifier of an inode in the file system. It allows the kernel to hold on to inodes, even if they have been unlinked from the underlying file system, regardless of whether they are opened or not. Notice how we removed a directory, and were still able to obtain its attributes afterwards using GETATTR. Sure, LOOKUP would obviously fail, as the object is no longer present in the file system under any name. Here is an implementation of FORGET that I wrote for Buildbarn: ![]() The FORGET operation allows you to determine when those files can be removed from the FUSE server's bookkeeping entirely. In that case you want the node IDs to remain valid, but refer to files that have already been unlinked from the file system hierarchy. ![]() > Besides, how many FUSE filesystems implement FORGET?Īny file system that wants to remove files in the background (meaning: not by calling unlink() through the FUSE mount) must likely do proper refcounting on such files, and provide an implementation of FORGET.įor example, a file system that can give information on live football matches may want to remove files/directories belonging to matches that have already ended. This doesn't seem to be documented explicitly, but is somewhat revealed by this printf(): Note that this is not a universal requirement, but at least one that the macOS NFSv4 client enforces. > I don't understand the comment about leaking memory, nfs file handles don't have to be persistent.Īs long as the file the NFSv4 file handle refers to is still usable (i.e., linked into the file system), the NFSv4 file handle must remain usable. This means that memory usage of fuse-t will most likely just keep on growing as time progresses? Or it announces itself as using file handle mode FH4_VOLATILE_*, but UNIX-like NFSv4 clients hardly ever know how to deal with that. Your FUSE file system's FORGET method will probably never be called. ![]() This means that if you implement FUSE on top of NFSv4, you will most likely not be able to purge any state. You therefore see that in-kernel implementations of NFS servers rely on special file system methods to resolve objects by file handle, in addition to being able to resolve by path. Only when the kernel issues a FORGET call, may the server drop information corresponding to a given nodeid.Īs NFSv4 is designed to be stateless, servers may need to be able to process requests containing arbitrary file handles, regardless of how long ago they were returned as part of some prior request. ![]() For example, with FUSE the kernel and server share intimate knowledge on which part of the file system lives in the kernel's inode cache. I do wonder how this library deals with some of the fundamental differences beween FUSE and NFSv4.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |