Implementing a new network based file system

Implementing a new network based file system

[Norbert Sendetzky]

Hi all

I'm currently doing some research on implementiation of a new file 
system for my diplomathesis. It's about designing and implementing a 
network file system with security in mind. For those interested, 
there is a short introduction about why and how on my website (look 
at the Secure Internet File System section):

http://www.linuxnetworks.de/security/index.html

I have already studied ramfs sources for the basics and the sources 
of coda, nfs and smbfs to find out, what I have to do. Also I read 
all documentation I found about the VFS. But there are a few 
questions, where I couldn't find an answer:


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?


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?


I have even more questions, but I will do some more research and 
maybe I will find the answer by myself before I get kicked off this 
list because of submitting too much obvious questions... (at least 
obvious to you) ;-)

Thanks in advance


Norbert

Re: Implementing a new network based file system

[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

Re: Implementing a new network based file system

[Dan Mann]

Well, if you get this thing off the ground, write a windows and mac client
for it.  That would be really nice.

Dan
----- Original Message -----
From: "Norbert Sendetzky" <norbert@linuxnetworks.de>
To: <linux-kernel@vger.kernel.org>
Sent: Friday, September 21, 2001 9:07 AM
Subject: Implementing a new network based file system


> Hi all
>
> I'm currently doing some research on implementiation of a new file
> system for my diplomathesis. It's about designing and implementing a
> network file system with security in mind. For those interested,
> there is a short introduction about why and how on my website (look
> at the Secure Internet File System section):
>
> http://www.linuxnetworks.de/security/index.html
>
> I have already studied ramfs sources for the basics and the sources
> of coda, nfs and smbfs to find out, what I have to do. Also I read
> all documentation I found about the VFS. But there are a few
> questions, where I couldn't find an answer:
>
>
> 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?
>
>
> 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?
>
>
> I have even more questions, but I will do some more research and
> maybe I will find the answer by myself before I get kicked off this
> list because of submitting too much obvious questions... (at least
> obvious to you) ;-)
>
> Thanks in advance
>
>
> Norbert
> -
> 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/
>

Re: Implementing a new network based file system

[Jan Hudec]

> Jan Harkes mentioned that getattr() don't have to be implemented (and 
> isn't implemented by nfs, smbfs and coda). Where do the VFS knows 
> about the attributes the users see? I haven't found any function in 
> inode_operation which gets a struct iattr* as parameter except 
> getattr() and setattr().
 
It should use getattr, but it merely reads them directly from the
inode structure. You just have to keep it up-to-date

> I suppose readpage() is handled in the same way. What about syncpage?

Readpage is is similar, except there's nothing like prepare and commit read.

I have not understood syncpage yet. Maybe someone else could elighten this bit.

> I have another question about the file_operations: How is locking 
> (file locking => file_operations->lock()) done by the VFS. I've read 
> about there is a flag in the inode structure which is set by flock(). 
> But this lock isn't known by the server. Is file_operations->lock() 
> called when defined?

Have not get to this yet either.

--------------------------------------------------------------------------------
                  				- Jan Hudec `Bulb' <bulb@ucw.cz>