2006-06-17T08:24:32Z 2006-06-17T08:24:32Z 2006-06-17T08:24:32Z http://neil.brown.name/blog/20060617082432 <p><br><br>I love todo-lists. They are liberating. If you don't know what to work on next, you write a TODO list. Then you just work through the things on the list. Or maybe you don't, but having written them all down, they no longer rattle around in your brain and distract you from more important things. <p>Anyway, to the point. Someone recently asked me what my priorities for the Linux NFS server were and while I'm not spending a lot of time on it at the moment, there are things that I would like to see done, so I wrote a little todo list. And having written it, I might as well share it. So here it is... <p><br><br><ul><li> auto-adjust the number of nfsd threads. I'd really like the sysadmin *not* to have to choose a number, but it should still be possible to set a maximum. I imagine: <ul><li> slow growth when there is high load and we have never had this many running before </li></ul> <ul><li> slow decay in numbers when &lt;50% are in use fast growth when we have dropped below the highwater mark and load is high </li></ul> <ul><li> A maximum that is somehow based on the requested number of threads </li></ul> <ul><li> Some way of measuring if extra threads in actually improving throughput, and feed that in to the growth calculations. </li></ul> </li></ul> <ul><li> Find a way to overcome the current bottle neck when replying to requests on a udp socket. </li></ul> <p><ul><li> explore whether it would help to make the scheduling of nfsd threads more SMP (and NUMA) aware. </li></ul> <p><ul><li> Finalise and implement upcall changes to support new NFSv4 features like auth-type selection and fs_locations </li></ul> <p><ul><li> make exporting of filesystem via NFSv4 work more smoothly (mountd should automatically create the 'virtual filesystem' thing). </li></ul> <p><br><br><p><a href=http://neil.brown.name/blog/20060617082432>(No comments)</a> 2004-06-08T15:24:45Z 2004-06-08T15:24:45Z http://neil.brown.name/blog/20040608152445 An NFS filehandle stores information to identify a filesystem (or directory in the filesystem that is the export point) and a file within that filesystem. <p>Identifying the file within the filesystem is now handled fairly well, but there are problems with identifying the filesystem. <p><a href=http://neil.brown.name/blog/20040608152445>read more...(No comments)</a> 2004-06-07T13:28:17Z 2004-06-07T13:28:17Z http://neil.brown.name/blog/20040607132817 Since mid 2000 I have been the official maintainer of the Linux NFS server - the in-kernel one rather than the user-space NFS server. A lot of progress has been made since then, but there is still work to do. <p>The following entries address various needs, how to approach them, and whether they have been addresses. <p>There should probably be a link to some patches here. But there isn't. Sorry about that. Maybe there will be soon when I get that more organised. <p><p><a href=http://neil.brown.name/blog/20040607132817>read more...(No comments)</a> 2004-05-13T10:01:20Z 2004-05-13T10:01:20Z http://neil.brown.name/blog/20040513100120 NFS (prior to V4) does not have a concept of opening and closing a file. The Linux VFS does include that concept. So the NFS server has to open the file before a READ or WRITE operation, and close it afterwards. <p>Some funcitonality in filesystems and in the VFS assumes that the open/close requests that are passed down correspond to opens and closes by the application, and that a particular &quot;file&quot; structure belongs to a particular application (possibly a group of processes). Thus he current open/IO/close approach does not give good information to filesystems <p><a href=http://neil.brown.name/blog/20040513100120>read more...(No comments)</a> 2004-05-12T17:17:38Z 2004-05-12T17:17:38Z http://neil.brown.name/blog/20040512171738 The COMMIT NFSv4 (and NFSv4) request asked to sync a range of a file. However the Linux VFS only allows a whole file to by synced <p><a href=http://neil.brown.name/blog/20040512171738>read more...(No comments)</a> 2004-05-12T17:14:42Z 2004-05-12T17:14:42Z http://neil.brown.name/blog/20040512171442 It would be really nice to have good RPCSEC/GSS support in nfs. <p><a href=http://neil.brown.name/blog/20040512171442>read more...(No comments)</a> 2004-05-12T13:40:00Z 2004-05-12T13:40:00Z http://neil.brown.name/blog/20040512134000 It is possible that IPv6 support would be useful in nfs. <p><a href=http://neil.brown.name/blog/20040512134000>read more...(No comments)</a> 2004-05-12T13:37:07Z 2004-05-12T13:37:07Z http://neil.brown.name/blog/20040512133707 There is probably some value in assigning some processor or NUMA-node affinity to nfsd server threads and possibly to sockets as well <p><a href=http://neil.brown.name/blog/20040512133707>read more...(No comments)</a> 2004-05-12T11:56:01Z 2004-05-12T11:56:01Z http://neil.brown.name/blog/20040512115601 The number of nfsd threads is currently static, though it can be changed from user-space. <p>There is value is having a dynamic number of threads. It means that the system administrator does not need to pick a number and hope it works. Even if the sysadmin is very clever, there will often be either too many threads, wasting memory, or too few causing uneeded delays. Having a dynamic number of threads means that the number can follow load. <p><a href=http://neil.brown.name/blog/20040512115601>read more...(No comments)</a>