Unknown date

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...

[permalink (No comments)]

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.

read more... (No comments)

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.

read more... (No comments)

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

read more... (No comments)

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

read more... (No comments)

12 May 2004, 17:14 UTCRPCSEC/GSS
It would be really nice to have good RPCSEC/GSS support in nfs.

read more... (No comments)

12 May 2004, 13:40 UTCIPv6 support
It is possible that IPv6 support would be useful in nfs.

read more... (No comments)

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

read more... (No comments)

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.

read more... (No comments)

[atom feed]