Messages in this thread |  | | Date | Fri, 21 Sep 2001 12:35:21 -0400 | Subject | Re: Implementing a new network based file system | From | Jan Harkes <> |
| |
On Fri, Sep 21, 2001 at 06:07:05PM +0200, Norbert Sendetzky wrote: > My first question is related to the superblock: > There are six functions about inode handling. Each of the above > network file systems (coda, nfs, smbfs) implements different > functions: > > coda: read_inode and clear_inode > nfs: read_inode, put_inode and delete_inode > smbfs: put_inode and delete_inode > > When do I need which function? Why are they necessary at all when > implementing a network file system? Can anyone explain the bigger > scheme behind this to me?
Any object (file/directory/symlink) needs an inode. You can either rely on the generic VFS iget (or iget4) implementation to find previously allocated inodes, in which case you need to have a read_inode function which is called whenever an inode is not found and a new one needs to be initialized. SMBFS is clearly using it's own methods for finding previously allocated inodes/allocating new ones, as it doesn't have an read_inode implementation.
Put_inode, delete_inode and clear_inode are all called in different places when inodes are released or destroyed, and can be used to tear down FS-private data structures. put_inode is called whenever iput is called, there might still be other references, so you need to check the i_count to see how many users there are left. delete_inode is probably related to deleted files, and clear_inode is only called when an inode is finally dropped from the inode cache and possibly given off to some other FS. Coda is able to use clear_inode, because we have a callback mechanism to invalidate inodes even when they are not in use anymore. This saves us a few calls to the userspace cachemanager, which are relatively expensive.
> My second question is around inode_operations: > Why does none of the network file systems implement the readlink, > follow_link, truncate and getattr funtions? Does the server follow > the symlink automatically if it is written to the storage medium and > show only the resulting file?
The VFS already does that for us, the only necessary function is an operation that returns the contents of the symbolic link (e.g. fs/coda/symlink.c).
btw. there is a linux-fsdevel mailinglist at vger.kernel.org where most FS hackers hang out. I guess that the #kernelnewbies IRC channel at irc.openprojects.net is also a goof place for these types of questions
Jan
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |