Regarding a Simple Version of nfs & nfsd

Regarding a Simple Version of nfs & nfsd

[UZAIR LAKHANI]

Hello All,

I myself want to write a network file system. I want
to find out how I can get the simplest version of nfs
and nfsd that implements the simplest file system
actions without any other features like the security
issues.

I want this type of nfs and nfsd code as to get the
help about how the file system routines are handled in
a network environment.

Upto now I am using Wrapfs (a wrapper file system)
code by Erez Zadok. That is I mount wrapfs on a mount
point and the read/write on the mount point will
actually be read/write on the underlying file system.

I want to extend this idea in to a network file sytem
i.e. the client does nothing but trasfers the
read/write request to the server which does the actual
read/write.

Any help will be useful.

Thanks,
Uzair Lakhani,
Karachi, Pakistan.

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

Re: Regarding a Simple Version of nfs & nfsd

[Avishay Traeger]

On Sun, 2006-03-19 at 20:18 -0800, UZAIR LAKHANI wrote:
> Hello All,
> 
> I myself want to write a network file system. I want
> to find out how I can get the simplest version of nfs
> and nfsd that implements the simplest file system
> actions without any other features like the security
> issues.
> 
> I want this type of nfs and nfsd code as to get the
> help about how the file system routines are handled in
> a network environment.
> 
> Upto now I am using Wrapfs (a wrapper file system)
> code by Erez Zadok. That is I mount wrapfs on a mount
> point and the read/write on the mount point will
> actually be read/write on the underlying file system.
> 
> I want to extend this idea in to a network file sytem
> i.e. the client does nothing but trasfers the
> read/write request to the server which does the actual
> read/write.

I don't think that you can implement NFS using a stackable file system.
A stackable file system sits between the VFS and a regular file system.
The stackable file system can change data, operations, etc. before
calling the lower level file system methods.  However, they cannot
change the transport method.

Avishay Traeger
http://www.fsl.cs.sunysb.edu/~avishay

Re: Regarding a Simple Version of nfs & nfsd

[Fawad Lateef]

On 3/21/06, Avishay Traeger <atraeger@cs.sunysb.edu> wrote:
> On Sun, 2006-03-19 at 20:18 -0800, UZAIR LAKHANI wrote:
> > I myself want to write a network file system. I want
> > to find out how I can get the simplest version of nfs
> > and nfsd that implements the simplest file system
> > actions without any other features like the security
> > issues.
> >
> > I want this type of nfs and nfsd code as to get the
> > help about how the file system routines are handled in
> > a network environment.
> >
> > Upto now I am using Wrapfs (a wrapper file system)
> > code by Erez Zadok. That is I mount wrapfs on a mount
> > point and the read/write on the mount point will
> > actually be read/write on the underlying file system.
> >
> > I want to extend this idea in to a network file sytem
> > i.e. the client does nothing but trasfers the
> > read/write request to the server which does the actual
> > read/write.
>
> I don't think that you can implement NFS using a stackable file system.
> A stackable file system sits between the VFS and a regular file system.
> The stackable file system can change data, operations, etc. before
> calling the lower level file system methods.  However, they cannot
> change the transport method.
>

I think stackable file system can be used as the server side daemon
with network communication support (somewhat like nfsd) which controls
the underlying file system (which can be any other normal fs) and as
far as client is concern it can act like a complete file system which
actually does nothing by it-self rather get data from the stackable fs
on the server (somewhat like nfs), so the client/user can use that
filesystem to mount the server filesystem. (I think Avishay this is
what Uzair wants to ask)


--
Fawad Lateef

Re: Regarding a Simple Version of nfs & nfsd

[Avishay Traeger]

On Tue, 2006-03-21 at 14:09 +0500, Fawad Lateef wrote:
> I think stackable file system can be used as the server side daemon
> with network communication support (somewhat like nfsd) which controls
> the underlying file system (which can be any other normal fs) 

Well I suppose you could do that, but you would be throwing out almost
all of the stackable file system code.  nfsd isn't really a file system
- it gets NFS requests from the network, and translates them to file
system requests.  No mounting, no inodes, etc.  It would be a waste of
time to start with a stackable file system, when the only stacking you
need to do is calling file system functions.

> and as
> far as client is concern it can act like a complete file system which
> actually does nothing by it-self rather get data from the stackable fs
> on the server (somewhat like nfs), so the client/user can use that
> filesystem to mount the server filesystem. (I think Avishay this is
> what Uzair wants to ask)

If the lower-level file system doesn't do anything, then what's the
point of stacking?  Of course, you can stack over NFS, but I think
that's cheating :).  Sure you can stack over something like ext2, and
send requests to the NFS server instead of ext2, but what's the point of
having ext2 there?


Avishay Traeger
http://www.fsl.cs.sunysb.edu/~avishay/

Re: Regarding a Simple Version of nfs & nfsd

[Fawad Lateef]

On 3/21/06, Avishay Traeger <atraeger@cs.sunysb.edu> wrote:
> On Tue, 2006-03-21 at 14:09 +0500, Fawad Lateef wrote:
> > I think stackable file system can be used as the server side daemon
> > with network communication support (somewhat like nfsd) which controls
> > the underlying file system (which can be any other normal fs)
>
> Well I suppose you could do that, but you would be throwing out almost
> all of the stackable file system code.  nfsd isn't really a file system
> - it gets NFS requests from the network, and translates them to file
> system requests.  No mounting, no inodes, etc.  It would be a waste of
> time to start with a stackable file system, when the only stacking you
> need to do is calling file system functions.
>

Ya, you are right. Stackable file system isn't needed but it can help
in understanding about  how stacking can be done :)

> > and as
> > far as client is concern it can act like a complete file system which
> > actually does nothing by it-self rather get data from the stackable fs
> > on the server (somewhat like nfs), so the client/user can use that
> > filesystem to mount the server filesystem. (I think Avishay this is
> > what Uzair wants to ask)
>
> If the lower-level file system doesn't do anything, then what's the
> point of stacking?  Of course, you can stack over NFS, but I think
> that's cheating :).  Sure you can stack over something like ext2, and
> send requests to the NFS server instead of ext2, but what's the point of
> having ext2 there?
>

What do you mean by lower-level file system ? The Client file system
must behave like a normal file system but it will perform fs requests
through the use of server daemon (which will act as a stack over fs
like ext2) and obviously I wasn't saying to use NFS or stack over it
rather create a complete different client file system according to
needs :)

--
Fawad Lateef

Re: Regarding a Simple Version of nfs & nfsd

[Avishay Traeger]

On Tue, 2006-03-21 at 18:33 +0500, Fawad Lateef wrote:
> What do you mean by lower-level file system ? The Client file system
> must behave like a normal file system but it will perform fs requests
> through the use of server daemon (which will act as a stack over fs
> like ext2) and obviously I wasn't saying to use NFS or stack over it
> rather create a complete different client file system according to
> needs :)


When you deal with stackable file systems, the "lower-level file system"
is the file system that you stack on top of.  So usually you have a
request come in through the VFS, into the stackable file system, and
then to the lower-level file system.  The way I see the design, you have
a stackable file system "simplenfs" over another file system
"lowerfs" (excuse the poor ascii art):

 |
 | sys_read()
 |
\_/
VFS
 | 
 | simplenfs_read()
 |
\_/
simplenfs ---> sends read request to server
 .
 .
 .
\_/
lowerfs


When simplenfs gets the reply from the server, it returns it to the VFS.
My question is what does lowerfs do if simplenfs is doing all the
communications with the server.

Avishay Traeger
http://www.fsl.cs.sunysb.edu/~avishay/

Re: Regarding a Simple Version of nfs & nfsd

[Fawad Lateef]

On 3/21/06, Avishay Traeger <atraeger@cs.sunysb.edu> wrote:
>
> When you deal with stackable file systems, the "lower-level file system"
> is the file system that you stack on top of.  So usually you have a
> request come in through the VFS, into the stackable file system, and
> then to the lower-level file system.  The way I see the design, you have
> a stackable file system "simplenfs" over another file system
> "lowerfs" (excuse the poor ascii art):
>
>  |
>  | sys_read()
>  |
> \_/
> VFS
>  |
>  | simplenfs_read()
>  |
> \_/
> simplenfs ---> sends read request to server
>  .
>  .
>  .
> \_/
> lowerfs
>
>
> When simplenfs gets the reply from the server, it returns it to the VFS.
> My question is what does lowerfs do if simplenfs is doing all the
> communications with the server.
>

Let me re-draw the diagram you mentioned with my idea. The ascii art :)

Client Side
     |
sys_read
     |
   vfs
     |
 client fs    ................... The fs running on client side, doing
nothing by itself, but provide support of mounting/unmounting,
readin/writing etc to client os
     |
  LAN
     |
stackable fs  .......... or you can say server daemon (accessing the real fs)
     |
   vfs
     |
  ext2

I hope now I able to make you clear my idea. Or you can suggest any
better than this. (I am just interested, not going to make this kind
of FS as don't have time. But your idea might help the person asking
question (Uzair))


--
Fawad Lateef

Re: Regarding a Simple Version of nfs & nfsd

[Avishay Traeger]

On Tue, 2006-03-21 at 20:27 +0500, Fawad Lateef wrote:
> Let me re-draw the diagram you mentioned with my idea. The ascii art :)
> 
> Client Side
>      |
> sys_read
>      |
>    vfs
>      |
>  client fs    ................... The fs running on client side, doing
> nothing by itself, but provide support of mounting/unmounting,
> readin/writing etc to client os
>      |
>   LAN
>      |
> stackable fs  .......... or you can say server daemon (accessing the real fs)
>      |
>    vfs
>      |
>   ext2
> 
> I hope now I able to make you clear my idea. Or you can suggest any
> better than this. (I am just interested, not going to make this kind
> of FS as don't have time. But your idea might help the person asking
> question (Uzair))

OK.  In the original e-mail, I believe the idea was to use stackable
file systems for both the client and the server.  In your design, you
only use it for the server, so I guess you agree with me that using it
on the client would be pointless.  And as we agreed earlier, using it on
the server isn't such a good idea either, as you will need to throw out
almost all of the code.


Avishay Traeger
http://www.fsl.cs.sunysb.edu/~avishay/

Re: Regarding a Simple Version of nfs & nfsd

[Fawad Lateef]

On 3/21/06, Avishay Traeger <atraeger@cs.sunysb.edu> wrote:
> On Tue, 2006-03-21 at 20:27 +0500, Fawad Lateef wrote:
> > Let me re-draw the diagram you mentioned with my idea. The ascii art :)
> >
> > Client Side
> >      |
> > sys_read
> >      |
> >    vfs
> >      |
> >  client fs    ................... The fs running on client side, doing
> > nothing by itself, but provide support of mounting/unmounting,
> > readin/writing etc to client os
> >      |
> >   LAN
> >      |
> > stackable fs  .......... or you can say server daemon (accessing the real fs)
> >      |
> >    vfs
> >      |
> >   ext2
> >
> > I hope now I able to make you clear my idea. Or you can suggest any
> > better than this. (I am just interested, not going to make this kind
> > of FS as don't have time. But your idea might help the person asking
> > question (Uzair))
>
> OK.  In the original e-mail, I believe the idea was to use stackable
> file systems for both the client and the server.  In your design, you
> only use it for the server, so I guess you agree with me that using it
> on the client would be pointless.  And as we agreed earlier, using it on
> the server isn't such a good idea either, as you will need to throw out
> almost all of the code.
>

Yes 100% agreed :) Now as I know your are good in file-system side, so
it will be good if you suggest some better or same idea along-with
some code examples (or some projects on something similar) for others
:)

--
Fawad Lateef

Re: Regarding a Simple Version of nfs & nfsd (RPC ISSUES)

[UZAIR LAKHANI]

Hello All,

Thank you Avishay Traeger and Fawad Lateef for having
a long discussion on my first mail.

Now I try to explain my own design.

Client FS -> read -> sys_read -> vfs_read ->
wrapper_fs_read -> RPC ... -> server_read

In the above design the client fs is a dummy fs which
only mimics a fs and passes requests to the wrapper fs
which by using RPC passes the requests to the server
which is a actual fs.

I am not considering overheads or performance issues
now.

Thanks,

Uzair Lakhani,
Karachi, Pakistan.
  


--- Fawad Lateef <fawadlateef@gmail.com> wrote:

> On 3/21/06, Avishay Traeger <atraeger@cs.sunysb.edu>
> wrote:
> > On Tue, 2006-03-21 at 20:27 +0500, Fawad Lateef
> wrote:
> > > Let me re-draw the diagram you mentioned with my
> idea. The ascii art :)
> > >
> > > Client Side
> > >      |
> > > sys_read
> > >      |
> > >    vfs
> > >      |
> > >  client fs    ................... The fs running
> on client side, doing
> > > nothing by itself, but provide support of
> mounting/unmounting,
> > > readin/writing etc to client os
> > >      |
> > >   LAN
> > >      |
> > > stackable fs  .......... or you can say server
> daemon (accessing the real fs)
> > >      |
> > >    vfs
> > >      |
> > >   ext2
> > >
> > > I hope now I able to make you clear my idea. Or
> you can suggest any
> > > better than this. (I am just interested, not
> going to make this kind
> > > of FS as don't have time. But your idea might
> help the person asking
> > > question (Uzair))
> >
> > OK.  In the original e-mail, I believe the idea
> was to use stackable
> > file systems for both the client and the server. 
> In your design, you
> > only use it for the server, so I guess you agree
> with me that using it
> > on the client would be pointless.  And as we
> agreed earlier, using it on
> > the server isn't such a good idea either, as you
> will need to throw out
> > almost all of the code.
> >
> 
> Yes 100% agreed :) Now as I know your are good in
> file-system side, so
> it will be good if you suggest some better or same
> idea along-with
> some code examples (or some projects on something
> similar) for others
> :)
> 
> --
> Fawad Lateef
> -
> To unsubscribe from this list: send the line
> "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at 
> http://vger.kernel.org/majordomo-info.html
> 


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

Re: Regarding a Simple Version of nfs & nfsd (RPC ISSUES)

[Fawad Lateef]

On 3/24/06, UZAIR LAKHANI <uzairr_bs1b@yahoo.com> wrote:
> Hello All,
>
> Thank you Avishay Traeger and Fawad Lateef for having
> a long discussion on my first mail.
>
> Now I try to explain my own design.
>
> Client FS -> read -> sys_read -> vfs_read ->
> wrapper_fs_read -> RPC ... -> server_read
>
> In the above design the client fs is a dummy fs which
> only mimics a fs and passes requests to the wrapper fs
> which by using RPC passes the requests to the server
> which is a actual fs.
>

I don't think your design is feasible Client FS will is the one which
gets request from VFS layer as user issues read which goes to sys_read
and then to vfs_read which in tern call your Client FS function for
reading and from here the request goes to server_read (can be through
RPC) which will act like a wrapper_fs_read and get the data from the
original FS and provide that back to the remote Client FS :) So the
architecture looking fine to me is like this:

User -> sys_read -> vfs_read -> client_fs_read -> RPC ->
wrapper_fs/server_fs_read -> underlying_fs_read -> storage


--
Fawad Lateef