Paweł Dziepak's blog

NFSv4 client: three quarter term report

Blog post by Paweł Dziepak on Mon, 2012-08-06 22:09
, ,

I've recently been working on caching in NFSv4 client. It was essential in order to allow the client to be comfortably used. I can gladly say that the traffic generated by NFS client has been greatly reduced, thanks to metadata, directory, lookup and file caching. I've also implemented support for open delegations which, though not always available, allow the client to perform virtually all file operations without immediate server participation.

NFSv4 client: midterm report

Blog post by Paweł Dziepak on Wed, 2012-07-11 16:58
, ,

Having implemented mandatory hooks by quarter term I had good base for implementing other operations like write, rename, create, etc. Moreover, improvements in file system migration and user ID mapping. Apart from that, file locks required most work, since they are both more complicated than other NFS operations and Haiku VFS originally did not allow the file system to handle them its own way.

NFSv4 client: quarter term report

Blog post by Paweł Dziepak on Sun, 2012-06-24 18:09

I have already implemented all mandatory hooks (and several others), what means that NFSv4 client now allows to browse directories and read files on remote filesystems. Last several days I spent on improving the existing code and supporting some less usual NFSv4 describes, that includes reclaiming share reservations, support for server migration and volatile filehandles. I also needed to deal with NFSv4 that do not provide file's inode number, that was solved only partially since proper workaround will be much easier to implement when file metadata and directory contents are cached.

NFSv4 client: community bonding report

Blog post by Paweł Dziepak on Mon, 2012-05-28 10:59
,

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.

I started working a few days before May 21st and the day the official coding started I already had a module that was able to generate and send NFSv4 null request and receive a reply using either TCP or UDP as transport protocol. In the first weekend I polished that code, added proper error handling, interpret RPC errors that might happen, made the client use only one TCP connection or UDP socket per server no matter how many file systems are mounted and added support for AUTH_SYS authentication flavor. Public backup of my work is available here.

Since most of RPC and XDR code is complete (apart from few issues I need to address) my next goal is to write NFSv4 request generation and reply interpretation. That will allow me to start writing hooks a FS module should provide. According to my initial timeline I had to have all mandatory hooks written by June 25th. However, now I think there is a big chance I will have that done by June 11th (quarter term).

GSoC Introduction: NFSv4 client

Blog post by Paweł Dziepak on Mon, 2012-04-30 02:04
, ,

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.

Community Bonding Period

During the community bonding period I am going to get myself familiar with every detail of all RFC containing information on how does NFS protocol works. That includes specifications of Remote Procedure Calls (RPC) and External Data Representation (XDR) which are used by NFS as well as the specification of NFSv4 itself. I think it may be also a good idea to check how NFS clients are implemented in other operating systems in order to find some interesting solutions.

I also need to get myself familiar with the Haiku itself. Specifically, with the parts of the kernel the NFSv4 will work with. That includes, among others, file caching, notifications, network. Since disk based file systems behave in a different way than NFS there may be need to make some changes in these parts of the code, so I will have to know exactly how to do it.

Summer and later

When I am ready with all preparations and the coding starts I am going to, firstly, write NFSv4 client that just works. That will require proper implementation of RPCs and basic NFS requests. Then I will be able to start making it usable, i.e. add client side caching, notifications, support for file attributes.

After GSoC, when NFSv4 client will be ready I will want to add support for NFSv4.1 mostly because of its interesting extensions such as directory delegation, which can improve notifications support or pNFS, parallel access to a clustered server implementation.

Syndicate content