During community bonding period, apart from reading specifications, I also analyzed other NFSv4 client implementations, looking for interesting ideas and solutions. One thing I noticed which may be worth using in my NFSv4 client implementation is caching of some parts of generated RPC request.
In addition to that I also got more familiar with what Haiku expects from file system modules. I have written a very simple dummy file system and check how things work. The problem I encountered here is that Haiku when creating a vnode identifies the file using its inode number. NFSv4 server provides its clients inode numbers but does not provide any way to get file using its inode number. That is why the client will have to keep some cache of inode numbers it is aware of in order to map them to NFSv4 file handles. Self-balancing BST seems to be a good idea.
My GSoC project is to implement a Network File System version 4 client. NFS since its early versions became one of the most popular way of sharing files among Unix-like (and not only) systems. The fourth version brings many changes to the protocol that both simplify implementation and make it more efficient. That includes better support of client side caching which can significantly improve performance. In addition to that neither mountd nor NLM needs to be used anymore since services they provide are now part of the protocol.
