Documentation/admin-guide/nfs/nfs-client.rst

Source file repositories/reference/linux-study-clean/Documentation/admin-guide/nfs/nfs-client.rst

File Facts

System
Linux kernel
Corpus path
Documentation/admin-guide/nfs/nfs-client.rst
Extension
.rst
Size
5462 bytes
Lines
145
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

==========
NFS Client
==========

The NFS client
==============

The NFS version 2 protocol was first documented in RFC1094 (March 1989).
Since then two more major releases of NFS have been published, with NFSv3
being documented in RFC1813 (June 1995), and NFSv4 in RFC3530 (April
2003).

The Linux NFS client currently supports all the above published versions,
and work is in progress on adding support for minor version 1 of the NFSv4
protocol.

The purpose of this document is to provide information on some of the
special features of the NFS client that can be configured by system
administrators.


The nfs4_unique_id parameter
============================

NFSv4 requires clients to identify themselves to servers with a unique
string.  File open and lock state shared between one client and one server
is associated with this identity.  To support robust NFSv4 state recovery
and transparent state migration, this identity string must not change
across client reboots.

Without any other intervention, the Linux client uses a string that contains
the local system's node name.  System administrators, however, often do not
take care to ensure that node names are fully qualified and do not change
over the lifetime of a client system.  Node names can have other
administrative requirements that require particular behavior that does not
work well as part of an nfs_client_id4 string.

The nfs.nfs4_unique_id boot parameter specifies a unique string that can be
used together with  a system's node name when an NFS client identifies itself to
a server.  Thus, if the system's node name is not unique, its
nfs.nfs4_unique_id can help prevent collisions with other clients.

The nfs.nfs4_unique_id string is typically a UUID, though it can contain
anything that is believed to be unique across all NFS clients.  An
nfs4_unique_id string should be chosen when a client system is installed,
just as a system's root file system gets a fresh UUID in its label at
install time.

The string should remain fixed for the lifetime of the client.  It can be
changed safely if care is taken that the client shuts down cleanly and all
outstanding NFSv4 state has expired, to prevent loss of NFSv4 state.

This string can be stored in an NFS client's grub.conf, or it can be provided
via a net boot facility such as PXE.  It may also be specified as an nfs.ko
module parameter.

This uniquifier string will be the same for all NFS clients running in
containers unless it is overridden by a value written to
/sys/fs/nfs/net/nfs_client/identifier which will be local to the network
namespace of the process which writes.


The DNS resolver
================

NFSv4 allows for one server to refer the NFS client to data that has been
migrated onto another server by means of the special "fs_locations"
attribute. See `RFC3530 Section 6: Filesystem Migration and Replication`_ and
`Implementation Guide for Referrals in NFSv4`_.

Annotation

Implementation Notes