Given that you've both expressed an interest in NFS client
development, I've finally gotten round to starting up a proper TODO
list.
The latter is by far exhaustive, but reflects a few of the
(IMHO) important development issues. If you're still interested in
doing something, please look through it, and inform me if you see
something that takes your fancy.
Updated versions can be retrieved at
http://www.fys.uio.no/~trondmy/TODO
I'll probably HTMLize the latter within the next few days, but since
it's taken me over a week to get this far, I thought I'd better
release as soon as possible ;-).
Please send me any other bugs/testcases/desired features (NFS client
only -- I'm leaving the server stuff to HJ and Allen) and I'll be
happy to include them...
Cheers,
Trond
-------------------------------------------------------------------
The following lists outstanding issues in the NFSv2 and NFSv3 client
development. It is not an exhaustive list, but reflects my current
knowledge of bugs and development issues.
Cheers,
Trond
NFSv2 (standard kernel)
=======================
1) Set up Web site with a FAQ.
2) Study effect of improved ordering of writes when flushing
files. How much writing speed can be gained by just optimizing for
write gathering servers, as opposed to supporting 8k wsize.
3) Study of inode staleness code. We currently try to keep a
consistent local state (mainly by looking at the nlinks). This
leads to problems when we have stale filehandles, renames and the
like. Is the 'locally stateful model' realistic, or should we move
to the sort of thing done in the NFSv3 code?
4) Fix rename to improve support for renaming of directories. This is
done in NFSv3, but relies on the new inode staleness stuff.
5) Fix the sillydelete code. I've sent on a patch (based on what is
done in NFSv3) to Linus, but he's uncertain about it. What
alternatives exist?
6) Back-port of NFSv3 sunrpc code. The latter is more stable and
supports NFS over TCP. It also supports improved flow control. This
is mainly a question of copying over the net/sunrpc subdir (minus
auth* ?) and fixing the redundant rpc_release_task calls in fs/nfs
and fs/lockd.
NFSv3 code (see patches in http://www.fys.uio.no/~trondmy/src/)
==========
1) Set up a Web site with a FAQ.
2) Rewrite of the writeback code. Look at something more like the
NFSv2 requests. The problem with the current code is that it is too
messy: too many layers. In particular, maintaining the 'cluster'
structure just for 8-32k wsize support seems like overkill (see
point 3).
3) Support for large rsize/wsize in the generic file read/write
code. Perhaps allow pages to be strung together as chains, and
allow generic routines to pass the entire chain to local read/write
code? The latter could easily be made transparent to other
filesystems.
4) Support for NFSv3 mounting under NFSroot.
5) Port to linux-2.3.x.
SunRPC code
===========
1) Is there still a problem with lack of socket buffer memory causing
network flooding?
2) Solve waiting problem with rpc_allocate. Current system of sleeping
for 1/4 second if no memory can be allocated is ugly.
-----------------------
Last updated 29/8/99...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/