Communicating FileSystem Structures b/w Two Machines

Communicating FileSystem Structures b/w Two Machines

[UZAIR LAKHANI]

Hello All,

I am in the process of making a filesystem in a
client/server environment where there is a single
server having a storage attached and 2 to 3 clients
accessing that storage through a communication
mechanism. The client and server are using a
buffer(unsigned char array) to communicate.

In order for client and server to communicate, they
have to exchange different structures like
super-block, inode, dentry, vfsmount etc. We have to
use 2.6.x kernels but since different versions of
kernel will have differnt sizes for these structures,
I am getting problems in communicating these
structures b/w client and server. I therefore want a
machine and kernel independent way for communicating
these structures so as to handle the sizes problem.

Your comments and help are welcomed.

Thanks,
Uzair Lakhani

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: Communicating FileSystem Structures b/w Two Machines

[Martin Jambor]

On 4/10/06, UZAIR LAKHANI <uzairr_bs1b@yahoo.com> wrote:
> In order for client and server to communicate, they
> have to exchange different structures like
> super-block, inode, dentry, vfsmount etc. We have to
> use 2.6.x kernels but since different versions of
> kernel will have differnt sizes for these structures,
> I am getting problems in communicating these
> structures b/w client and server. I therefore want a
> machine and kernel independent way for communicating
> these structures so as to handle the sizes problem.

1. Use types like le32 and u64 and so on so that all fields of the
structures you pass between machines have the same size everywhere.

2. Take care of endianness. (use macros like __cpu_to_le64 and the
like when reading/storing multibyte numbers).

3. Prevent the compiler from padding the structures by using the
__packed__ gcc directive.

I hope that's all.

Examples can be found e.g. in include/linux/eiserfs_fs.h (and many
other places).

HTH

Martin

Re: Communicating FileSystem Structures b/w Two Machines

[Matthew Wilcox]

On Sun, Apr 09, 2006 at 11:11:46PM -0700, UZAIR LAKHANI wrote:
> I am in the process of making a filesystem in a
> client/server environment where there is a single
> server having a storage attached and 2 to 3 clients
> accessing that storage through a communication
> mechanism. The client and server are using a
> buffer(unsigned char array) to communicate.
> 
> In order for client and server to communicate, they
> have to exchange different structures like
> super-block, inode, dentry, vfsmount etc.

Why on earth do you think that?  Certainly you have to communicate
file data and metadata, but why on earth would you ship dentries from
one machine to another?  This will never work.

You should probably look at how other network filesystems are designed,
starting with NFS: http://www.faqs.org/rfcs/rfc1094.html

What are your research goals for this new filesystem?  Why will it be
any better than OCFS2, NFS (v2 or v4), SMBFS/CIFS, NCPFS, Coda or AFS?
Why don't you start by taking one of these filesystems and modify or
extend it to suit your needs rather than starting from scratch?

Re: Communicating FileSystem Structures b/w Two Machines

[Fawad Lateef]

On 4/10/06, UZAIR LAKHANI <uzairr_bs1b@yahoo.com> wrote:
>
<snip>
> In order for client and server to communicate, they
> have to exchange different structures like
> super-block, inode, dentry, vfsmount etc. We have to
> use 2.6.x kernels but since different versions of
> kernel will have differnt sizes for these structures,
> I am getting problems in communicating these
> structures b/w client and server. I therefore want a
> machine and kernel independent way for communicating
> these structures so as to handle the sizes problem.
>

As Martin Jambor already gave some good points for structure size
problems among different machines and I just want to add one more
thing:

Why are you going to transfer superblock, inodes, dentries etc ? I
think you just need to transfer the information necessary (meta-data)
(like permissions, directory structure etc) between client/server
besides the actual file data. And for this you need to create a proper
protocol which you actually send as a payload in TCP/IP or other
protocol packet (you can get idea from NFS's protocol)

I hope this helps

--
Fawad Lateef