<commit_before>NFSv4.1 Server Implementation

Server support for minorversion 1 can be controlled using the
/proc/fs/nfsd/versions control file.  The string output returned
by reading this file will contain either "+4.1" or "-4.1"
correspondingly.

Currently, server support for minorversion 1 is disabled by default.
It can be enabled at run time by writing the string "+4.1" to
the /proc/fs/nfsd/versions control file.  Note that to write this
control file, the nfsd service must be taken down.  Use your user-mode
nfs-utils to set this up; see rpc.nfsd(8)

(Warning: older servers will interpret "+4.1" and "-4.1" as "+4" and
"-4", respectively.  Therefore, code meant to work on both new and old
kernels must turn 4.1 on or off *before* turning support for version 4
on or off; rpc.nfsd does this correctly.)

The NFSv4 minorversion 1 (NFSv4.1) implementation in nfsd is based
on the latest NFSv4.1 Internet Draft:
http://tools.ietf.org/html/draft-ietf-nfsv4-minorversion1-29

From the many new features in NFSv4.1 the current implementation
focuses on the mandatory-to-implement NFSv4.1 Sessions, providing
"exactly once" semantics and better control and throttling of the
resources allocated for each client.

Other NFSv4.1 features, Parallel NFS operations in particular,
are still under development out of tree.
See http://wiki.linux-nfs.org/wiki/index.php/PNFS_prototype_design
for more information.

The current implementation is intended for developers only: while it
does support ordinary file operations on clients we have tested against
(including the linux client), it is incomplete in ways which may limit
features unexpectedly, cause known bugs in rare cases, or cause
interoperability problems with future clients.  Known issues:

	- gss support is questionable: currently mounts with kerberos
	  from a linux client are possible, but we aren't really
	  conformant with the spec (for example, we don't use kerberos
	  on the backchannel correctly).
	- no trunking support: no clients currently take advantage of
	  trunking, but this is a mandatory feature, and its use is
	  recommended to clients in a number of places.  (E.g. to ensure
	  timely renewal in case an existing connection's retry timeouts
	  have gotten too long; see section 8.3 of the draft.)
	  Therefore, lack of this feature may cause future clients to
	  fail.
	- Incomplete backchannel support: incomplete backchannel gss
	  support and no support for BACKCHANNEL_CTL mean that
	  callbacks (hence delegations and layouts) may not be
	  available and clients confused by the incomplete
	  implementation may fail.
	- Server reboot recovery is unsupported; if the server reboots,
	  clients may fail.
	- We do not support SSV, which provides security for shared
	  client-server state (thus preventing unauthorized tampering
	  with locks and opens, for example).  It is mandatory for
	  servers to support this, though no clients use it yet.
	- Mandatory operations which we do not support, such as
	  DESTROY_CLIENTID, FREE_STATEID, SECINFO_NO_NAME, and
	  TEST_STATEID, are not currently used by clients, but will be
	  (and the spec recommends their uses in common cases), and
	  clients should not be expected to know how to recover from the
	  case where they are not supported.  This will eventually cause
	  interoperability failures.

In addition, some limitations are inherited from the current NFSv4
implementation:

	- Incomplete delegation enforcement: if a file is renamed or
	  unlinked, a client holding a delegation may continue to
	  indefinitely allow opens of the file under the old name.

The table below, taken from the NFSv4.1 document, lists
the operations that are mandatory to implement (REQ), optional<commit_msg>nfsd: 4.1 has an rfc number<commit_after>NFSv4.1 Server Implementation

Server support for minorversion 1 can be controlled using the
/proc/fs/nfsd/versions control file.  The string output returned
by reading this file will contain either "+4.1" or "-4.1"
correspondingly.

Currently, server support for minorversion 1 is disabled by default.
It can be enabled at run time by writing the string "+4.1" to
the /proc/fs/nfsd/versions control file.  Note that to write this
control file, the nfsd service must be taken down.  Use your user-mode
nfs-utils to set this up; see rpc.nfsd(8)

(Warning: older servers will interpret "+4.1" and "-4.1" as "+4" and
"-4", respectively.  Therefore, code meant to work on both new and old
kernels must turn 4.1 on or off *before* turning support for version 4
on or off; rpc.nfsd does this correctly.)

The NFSv4 minorversion 1 (NFSv4.1) implementation in nfsd is based
on RFC 5661.

From the many new features in NFSv4.1 the current implementation
focuses on the mandatory-to-implement NFSv4.1 Sessions, providing
"exactly once" semantics and better control and throttling of the
resources allocated for each client.

Other NFSv4.1 features, Parallel NFS operations in particular,
are still under development out of tree.
See http://wiki.linux-nfs.org/wiki/index.php/PNFS_prototype_design
for more information.

The current implementation is intended for developers only: while it
does support ordinary file operations on clients we have tested against
(including the linux client), it is incomplete in ways which may limit
features unexpectedly, cause known bugs in rare cases, or cause
interoperability problems with future clients.  Known issues:

	- gss support is questionable: currently mounts with kerberos
	  from a linux client are possible, but we aren't really
	  conformant with the spec (for example, we don't use kerberos
	  on the backchannel correctly).
	- no trunking support: no clients currently take advantage of
	  trunking, but this is a mandatory feature, and its use is
	  recommended to clients in a number of places.  (E.g. to ensure
	  timely renewal in case an existing connection's retry timeouts
	  have gotten too long; see section 8.3 of the RFC.)
	  Therefore, lack of this feature may cause future clients to
	  fail.
	- Incomplete backchannel support: incomplete backchannel gss
	  support and no support for BACKCHANNEL_CTL mean that
	  callbacks (hence delegations and layouts) may not be
	  available and clients confused by the incomplete
	  implementation may fail.
	- Server reboot recovery is unsupported; if the server reboots,
	  clients may fail.
	- We do not support SSV, which provides security for shared
	  client-server state (thus preventing unauthorized tampering
	  with locks and opens, for example).  It is mandatory for
	  servers to support this, though no clients use it yet.
	- Mandatory operations which we do not support, such as
	  DESTROY_CLIENTID, FREE_STATEID, SECINFO_NO_NAME, and
	  TEST_STATEID, are not currently used by clients, but will be
	  (and the spec recommends their uses in common cases), and
	  clients should not be expected to know how to recover from the
	  case where they are not supported.  This will eventually cause
	  interoperability failures.

In addition, some limitations are inherited from the current NFSv4
implementation:

	- Incomplete delegation enforcement: if a file is renamed or
	  unlinked, a client holding a delegation may continue to
	  indefinitely allow opens of the file under the old name.

The table below, taken from the NFSv4.1 document, lists
the operations that are mandatory to implement (REQ), optional
{'fraction_non_alphanumeric': 0.046291283161884134, 'fraction_numerical': 0.011099079588521927, 'mean_word_length': 4.1563154221912075, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '6638030', 'n_tokens_mistral': 2057, 'n_tokens_neox': 1925, 'n_words': 1062}