Annotation of wikisrc/projects/project/fs-services.mdwn, revision 1.7

1.1       jmmv        1: [[!template id=project
                      3: title="File Systems as Network Services"
                      5: contact="""
1.7     ! dholland    6: [tech-userlevel](,
        !             7: [tech-kern](
1.1       jmmv        8: """
1.4       dholland   10: category="filesystems"
1.7     ! dholland   11: difficulty="hard"
1.1       jmmv       12: duration="3 months"
                     14: description="""
                     15: 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.
                     17: 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]( and [rump]( 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.
1.5       mspo       19: The milestones are the following:
1.1       jmmv       20: 
                     21: * 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.
                     23:     Proof-of-concept code for this has already been written.
                     25: * 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.
                     27: * To be able to handle multiple clients, the file systems must be converted to daemons instead of being utilities. This will also, in the case of kernel file system servers, include adding locking to the communication protocol.
                     29: The end result will look something like this:
                     31:     # start serving ffs from /dev/wd0a on port 12675
                     32:     onehost> ffs_serv -p 12675 /dev/wd0a
                     33:     # start serving cd9660 from /dev/cd0a on port 12676
                     34:     onehost> cd9660_serv -p 12675 /dev/cd0a
                     36:     # meanwhile in outer space, mount anotherhost from port 12675
                     37:     anotherhost> mount_puffs -t tcp onehost:12675 /mnt
                     38:     anotherhost> mount
                     39:     ...
                     40:     anotherhost:12675 on /mnt type <negotiated>
                     41:     ...
                     42:     anotherhost> cd /mnt
                     43:     anotherhost> ls
                     44:       ... etc
                     46: 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?"
                     47: """
                     48: ]]

CVSweb for NetBSD wikisrc <> software: FreeBSD-CVSweb