To do

From Linux NFS

(Difference between revisions)
Jump to: navigation, search
 
(6 intermediate revisions not shown)
Line 1: Line 1:
-
Specific high-priority to-do lists:
+
Specific prioritized to-do lists, being actively worked on:
-
* [[Client sessions_Implementation_Issues]]
+
* [[Client sessions Implementation Issues]]
-
* [[Client pNFS deliverables]]
+
* [[Client pnfs deliverables]]
 +
* [[Server 4.0 and 4.1 issues]]
 +
* [[Server pNFS issues]]
 +
* [[4.1 RDMA issues]]
Some specific projects; follow links for more details on design requirements and implementation plans.  If you intend to work on any of these, please keep in close contact with other developers, using linux-nfs@vger.kernel.org.
Some specific projects; follow links for more details on design requirements and implementation plans.  If you intend to work on any of these, please keep in close contact with other developers, using linux-nfs@vger.kernel.org.
-
Projects that are easier or more self-contained:
+
* [[Server export issues]]
-
 
+
* idmapd/gssd warn on absence of dnotify: idmapd and gssd both depend on dnotify to find out about changes in rpc_pipefs.  Therefore, both fail on a kernel compiled without CONFIG_DNOTIFY.  It is not at all obvious from the failure, however, what the problem is.  Patch nfs-utils to report a helpful error in this case.
* idmapd/gssd warn on absence of dnotify: idmapd and gssd both depend on dnotify to find out about changes in rpc_pipefs.  Therefore, both fail on a kernel compiled without CONFIG_DNOTIFY.  It is not at all obvious from the failure, however, what the problem is.  Patch nfs-utils to report a helpful error in this case.
-
* old kernels sometimes sent large uid's in server idmap upcalls as negative numbers.  The server has been fixed not to do that.  But probably it should have handled them (by converting to unsigned u32?).  Also reports has it that idmapd would cease accepting any upcalls after that failure; investigate the cause of that.
 
* [[fix nfsd verify operation]]: nfsd's "verify" and "nverify" operations need to be rewritten to make them reliable.
* [[fix nfsd verify operation]]: nfsd's "verify" and "nverify" operations need to be rewritten to make them reliable.
* [[error reporting]]: It's easier for people to set up nfsv4 and krb5 if we give people informative error messages when something is wrong.
* [[error reporting]]: It's easier for people to set up nfsv4 and krb5 if we give people informative error messages when something is wrong.
Line 20: Line 21:
* warn about inconsistent fsid= options: specifying fsid=x for multiple different filesystems (and the same x) is another obvious sign that something's wrong with the exports file.  Warn on that too.  And probably warn if fsid= is changed on existing export--it may be necessary sometimes, but it's likely to mess up any active clients.
* warn about inconsistent fsid= options: specifying fsid=x for multiple different filesystems (and the same x) is another obvious sign that something's wrong with the exports file.  Warn on that too.  And probably warn if fsid= is changed on existing export--it may be necessary sometimes, but it's likely to mess up any active clients.
* [[warn about inconsistent security requirements]]: If you export a subdirectory with more security flavors than the parent, you may confuse clients.  Warn about these cases in exportfs?
* [[warn about inconsistent security requirements]]: If you export a subdirectory with more security flavors than the parent, you may confuse clients.  Warn about these cases in exportfs?
 +
* [[NFS for AFS users]]
-
More open-ended projects, that will require close collaboration with other developers, and possibly multiple attempts:
 
-
 
-
* [[newpynfs bug-chasing]]: Run latest [http://www.citi.umich.edu/projects/nfsv4/pynfs/ newpynfs] tests, diagnose and fix bugs.  Some of this is easy, some is hard, requires knowing what to pay attention to.  (E.g.: for now we don't plan to fix utf8 bugs, so ignore those.)
 
-
* [[pseudofilesystem improvements]]: The NFSv4 server currently patches together export paths in a way that is inconsistent with NFSv2 and NFSv3 and causes severe problems for automount users.
 
-
\
 
See also (priority lists somewhat out of date):
See also (priority lists somewhat out of date):

Latest revision as of 15:03, 13 July 2020

Specific prioritized to-do lists, being actively worked on:

Some specific projects; follow links for more details on design requirements and implementation plans. If you intend to work on any of these, please keep in close contact with other developers, using linux-nfs@vger.kernel.org.

  • Server export issues
  • idmapd/gssd warn on absence of dnotify: idmapd and gssd both depend on dnotify to find out about changes in rpc_pipefs. Therefore, both fail on a kernel compiled without CONFIG_DNOTIFY. It is not at all obvious from the failure, however, what the problem is. Patch nfs-utils to report a helpful error in this case.
  • fix nfsd verify operation: nfsd's "verify" and "nverify" operations need to be rewritten to make them reliable.
  • error reporting: It's easier for people to set up nfsv4 and krb5 if we give people informative error messages when something is wrong.
  • nfs-utils unit tests: Implement a unit test infrastructure in the nfs-utils tree.
  • nfs-utils internationalization: Add full support for double-wide character sets, and use message catalogs everywhere. Find translators for the catalogs.
  • client ACL tools: The client ACL utilities need some work
  • wireshark improvements: Wireshark (previously known as ethereal) is useful for debugging NFSv4 problems. But it could be more useful.
  • remove gss code from libnfsidmap: we're doing gss principal-to-uid-mapping in libnfsidmap. This introduces a problematic dependancy of libnfsidmap on gss. We should just move that mapping code to svcgssd, which is the only place it's needed.
  • printk cleanup: make sure the information that goes to the logs is the information we need.
  • warn about unsafe exports: exporting a subdirectory of a filesystem generally also makes the rest of the filesystem available (all someone need do is guess the root filehandle, which is usually very easy). It's not clear that users realize this. Add code to exportfs to warn about suspicious-looking cases.
  • warn about inconsistent fsid= options: specifying fsid=x for multiple different filesystems (and the same x) is another obvious sign that something's wrong with the exports file. Warn on that too. And probably warn if fsid= is changed on existing export--it may be necessary sometimes, but it's likely to mess up any active clients.
  • warn about inconsistent security requirements: If you export a subdirectory with more security flavors than the parent, you may confuse clients. Warn about these cases in exportfs?
  • NFS for AFS users

See also (priority lists somewhat out of date):

Personal tools