lkml.org 
[lkml]   [2001]   [Sep]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: Implementing a new network based file system
From
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/

\
 
 \ /
  Last update: 2005-03-22 13:03    [W:0.076 / U:0.368 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site