17 June 2006, 08:24 UTCAnother TODO list : nfsd
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.
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...
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.
- slow growth when there is high load and we have never had this many running before
- slow decay in numbers when <50% are in use fast growth when we have dropped below the highwater mark and load is high
- A maximum that is somehow based on the requested number of threads
- Some way of measuring if extra threads in actually improving throughput, and feed that in to the growth calculations.
- Find a way to overcome the current bottle neck when replying to requests on a udp socket.
- explore whether it would help to make the scheduling of nfsd threads more SMP (and NUMA) aware.
- Finalise and implement upcall changes to support new NFSv4 features like auth-type selection and fs_locations
- make exporting of filesystem via NFSv4 work more smoothly (mountd should automatically create the 'virtual filesystem' thing).
08 June 2004, 15:24 UTCBetter FSID management
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.
Identifying the file within the filesystem is now handled fairly well, but there are problems with identifying the filesystem.
07 June 2004, 13:28 UTCLinux NFS server
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.
The following entries address various needs, how to approach them, and whether they have been addresses.
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.
13 May 2004, 10:01 UTCBetter read-ahead management and other file-open issues
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.
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 "file" 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
12 May 2004, 17:17 UTCMore efficient COMMIT
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
12 May 2004, 17:14 UTCRPCSEC/GSS
It would be really nice to have good RPCSEC/GSS support in nfs.
12 May 2004, 13:40 UTCIPv6 support
It is possible that IPv6 support would be useful in nfs.
12 May 2004, 13:37 UTCSMP afinity for threads and sockets
There is probably some value in assigning some processor or NUMA-node affinity to nfsd server threads and possibly to sockets as well
12 May 2004, 11:56 UTCDynamic thread count
The number of nfsd threads is currently static, though it can be changed from user-space.
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.