Diff for /wikisrc/projects/project/fs-services.mdwn between versions 1.7 and 1.8

version 1.7, 2016/08/26 19:45:11 version 1.8, 2016/08/26 19:58:01
Line 1 Line 1
 [[!template id=project  [[!template id=project
   
 title="File Systems as Network Services"  title="Networked file systems using puffs"
   
 contact="""  contact="""
 [tech-userlevel](mailto:tech-userlevel@NetBSD.org),  [tech-userlevel](mailto:tech-userlevel@NetBSD.org),
Line 12  difficulty="hard" Line 12  difficulty="hard"
 duration="3 months"  duration="3 months"
   
 description="""  description="""
 File systems are historically mounted by specifying which type of file system is mounted from where (e.g. `mount -t ffs /dev/wd0a /mnt`). However, sometimes a user is only interested in making the data available and not particularly interested in how or from where it is made available.  The existing puffs protocol gives a way to forward kernel-level file
   system actions to a userspace process. This project generalizes that
   protocol to allow forwarding file system actions arbitrarily across a
   network. This will make it possible to mount any kernel file system
   type from any location on the network, given a suitable arrangement of
   components.
   
 This project investigates the first steps in turning file systems into network-transparent services by making it possible to mount any kernel file system type from any location on the network. The file system components to be used are [puffs](http://www.netbsd.org/docs/puffs/) and [rump](http://www.netbsd.org/docs/puffs/rump.html). puffs is used to forward local file system requests from the kernel to userspace and rump is used to facilitate running the kernel file system in userspace as a service daemon.  The file system components to be used are [puffs](http://www.netbsd.org/docs/puffs/) and [rump](http://www.netbsd.org/docs/puffs/rump.html). puffs is used to forward local file system requests from the kernel to userspace and rump is used to facilitate running the kernel file system in userspace as a service daemon.
   
 The milestones are the following:  The milestones are the following:
   
 * Write the necessary code to be able to forward requests from one source to another. This involves most likely reworking a bit of the libpuffs option parsing code and creating an puffs client, say, mount_puffs to be able to forward requests from one location to another. The puffs protocol should be extended to include the necessary new features or another protocol defined.  * Write the necessary code to be able to forward requests from one source to another. This involves most likely reworking a bit of the libpuffs option parsing code and creating a puffs client (say, mount_puffs) to be able to forward requests from one location to another. The puffs protocol should be extended to include the necessary new features or a new protocol invented.
   
     Proof-of-concept code for this has already been written.      Proof-of-concept code for this has already been written. (Where is it?)
   
 * Currently the puffs protocol used for communication between the kernel and userland is machine dependent. To facilitate forwarding the protocol to remote hosts, a machine independent version must be specified.  * Currently the puffs protocol used for communication between the kernel and userland is machine dependent. To facilitate forwarding the protocol to remote hosts, a machine independent version must be specified.
   
Line 43  The end result will look something like  Line 48  The end result will look something like 
     anotherhost> ls      anotherhost> ls
       ... etc        ... etc
   
 The student should have some familiarity with file systems and network services. The application should include an answer to the following question: "how is this different from nfs?"  The implementor should have some familiarity with file systems and network services.
   
   Any proposal should include answers to at least the following questions:
   
   * How is this different from NFS?
   
   * How is the protocol different from 9p?
   
   * How is this scheme going to handle the hard things that NFS doesn't do very well, such as distributed cache consistency?
   
   * Given industry trends, why is this project proposing a new protocol instead of conforming to the SOA model?
   
 """  """
 ]]  ]]

Removed from v.1.7  
changed lines
  Added in v.1.8


CVSweb for NetBSD wikisrc <wikimaster@NetBSD.org> software: FreeBSD-CVSweb