Re: Implementing a new network based file system

[Jan Harkes <jaharkes@cs.cmu.edu>]

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