1
0
mirror of https://git.FreeBSD.org/src.git synced 2025-01-05 12:56:08 +00:00

nfsd: Fix some issues found by mandoc

- consider using OS macro: Fx

Reviewed by:	bcr
MFC after:	1 week
Differential Revision:	https://reviews.freebsd.org/D31145
This commit is contained in:
Gordon Bergling 2021-07-12 06:31:54 +02:00
parent 0b12932525
commit 4c87085d35
3 changed files with 72 additions and 24 deletions

View File

@ -143,7 +143,9 @@ by default.
However, this can normally be overridden by a command line
option or configuration file for the daemon used to do the name<->number
mapping.
Under FreeBSD, the mapping daemon is called
Under
.Fx ,
the mapping daemon is called
.Xr nfsuserd 8
and has a command line option that overrides the domain component of the
machine's hostname.

View File

@ -54,10 +54,14 @@ the DS.
The first is DeviceInfo, which is static information defining the DS
server.
The critical piece of information in DeviceInfo for the layout types
supported by FreeBSD is the IP address that is used to perform RPCs on the DS.
supported by
.Fx
is the IP address that is used to perform RPCs on the DS.
It also indicates which version of NFS the DS supports, I/O size and other
layout specific information.
In the DeviceInfo, there is a DeviceID which, for the FreeBSD server
In the DeviceInfo, there is a DeviceID which, for the
.Fx
server
is unique to the DS configuration
and changes whenever the
.Xr nfsd
@ -66,35 +70,51 @@ daemon is restarted or the server is rebooted.
The second is the layout, which is per file and references the DeviceInfo
to use via the DeviceID.
It is for a byte range of a file and is either Read or Read/Write.
For the FreeBSD server, a layout covers all bytes of a file.
For the
.Fx
server, a layout covers all bytes of a file.
A layout may be recalled by the MDS using a LayoutRecall callback.
When a client returns a layout via the LayoutReturn operation it can
indicate that error(s) were encountered while doing I/O on the DS,
at least for certain layout types such as the Flexible File Layout.
.Pp
The FreeBSD client and server supports two layout types.
The
.Fx
client and server supports two layout types.
.Pp
The File Layout is described in RFC5661 and uses the NFSv4.1 or NFSv4.2 protocol
to perform I/O on the DS.
It does not support client aware DS mirroring and, as such,
the FreeBSD server only provides File Layout support for non-mirrored
the
.Fx
server only provides File Layout support for non-mirrored
configurations.
.Pp
The Flexible File Layout allows the use of the NFSv3, NFSv4.0, NFSv4.1 or
NFSv4.2 protocol to perform I/O on the DS and does support client aware
mirroring.
As such, the FreeBSD server uses Flexible File Layout layouts for the
As such, the
.Fx
server uses Flexible File Layout layouts for the
mirrored DS configurations.
The FreeBSD server supports the
The
.Fx
server supports the
.Dq tightly coupled
variant and all DSs allow use of the
NFSv4.2 or NFSv4.1 protocol for I/O operations.
Clients that support the Flexible File Layout will do writes and commits
to all DS mirrors in the mirror set.
.Pp
A FreeBSD pNFS service consists of a single MDS server plus one or more
DS servers, all of which are FreeBSD systems.
For a non-mirrored configuration, the FreeBSD server will issue File Layout
A
.Fx
pNFS service consists of a single MDS server plus one or more
DS servers, all of which are
.Fx
systems.
For a non-mirrored configuration, the
.Fx
server will issue File Layout
layouts by default.
However that default can be set to the Flexible File Layout by setting the
.Xr sysctl 1
@ -105,7 +125,8 @@ Mirrored server configurations will only issue Flexible File Layouts.
.Tn pNFS
clients mount the MDS as they would a single NFS server.
.Pp
A FreeBSD
A
.Fx
.Tn pNFS
client must be running the
.Xr nfscbd 8
@ -165,7 +186,9 @@ as a mirror while the pNFS service continues to function.
.Pp
See
.Xr pnfsserver 4
for information on how to set up a FreeBSD pNFS service.
for information on how to set up a
.Fx
pNFS service.
.Sh SEE ALSO
.Xr nfsv4 4 ,
.Xr pnfsserver 4 ,
@ -187,7 +210,9 @@ For Linux 4.17-rc2 kernels, I have not seen client crashes during testing,
but it only supports the
.Dq loosely coupled
variant.
To make it work correctly when mounting the FreeBSD server, you must
To make it work correctly when mounting the
.Fx
server, you must
set the sysctl
.Dq vfs.nfsd.flexlinuxhack
to one so that it works around

View File

@ -30,14 +30,22 @@
.Nm pNFSserver
.Nd NFS Version 4.1 and 4.2 Parallel NFS Protocol Server
.Sh DESCRIPTION
A set of FreeBSD servers may be configured to provide a
A set of
.Fx
servers may be configured to provide a
.Xr pnfs 4
service.
One FreeBSD system needs to be configured as a MetaData Server (MDS) and
at least one additional FreeBSD system needs to be configured as one or
One
.Fx
system needs to be configured as a MetaData Server (MDS) and
at least one additional
.Fx
system needs to be configured as one or
more Data Servers (DS)s.
.Pp
These FreeBSD systems are configured to be NFSv4.1 and NFSv4.2
These
.Fx
systems are configured to be NFSv4.1 and NFSv4.2
servers, see
.Xr nfsd 8
and
@ -85,7 +93,9 @@ not require the
export option and this directory should be exported to them with the same
options as used by the MDS to export file system(s) to the clients.
.Pp
It is possible to have multiple DSs on the same FreeBSD system, but each
It is possible to have multiple DSs on the same
.Fx
system, but each
of these DSs must have a separate top level exported directory used for storage
of data files and each
of these DSs must be mountable via a separate IP address.
@ -94,10 +104,15 @@ interface via
.Xr ifconfig 8
to create these different IP addresses.
Multiple DSs on the same server may be useful when data for different file systems
on the MDS are being stored on different file system volumes on the FreeBSD
on the MDS are being stored on different file system volumes on the
.Fx
DS system.
.Sh MDS server configuration
The MDS must be a separate FreeBSD system from the FreeBSD DS system(s) and
The MDS must be a separate
.Fx
system from the
.Fx
DS system(s) and
NFS clients.
It is configured as a NFSv4.1 and NFSv4.2 server with
file system(s) exported to clients.
@ -189,7 +204,9 @@ nfs_server_flags="-u -t -n 128 -p nfsv4-data0:/data0#/export1,nfsv4-data1:/data1
This can be used by system administrators to control where data files are
stored and might be useful for control of storage use.
For this case, it may be convenient to co-locate more than one of the DSs
on the same FreeBSD server, using separate file systems on the DS system
on the same
.Fx
server, using separate file systems on the DS system
for storage of the respective DS's data files.
If mirroring is desired for this case, the
.Dq -m
@ -211,7 +228,9 @@ For a service that will store a large number of files this sysctl should be
set much larger, to avoid the number of entries in a subdirectory from
getting too large.
.Sh Client mounts
Once operational, NFSv4.1 or NFSv4.2 FreeBSD client mounts
Once operational, NFSv4.1 or NFSv4.2
.Fx
client mounts
done with the
.Dq pnfs
option should do I/O directly on the DSs.
@ -421,5 +440,7 @@ Since the MDS cannot be mirrored, it is a single point of failure just
as a non
.Tn pNFS
server is.
For non-mirrored configurations, all FreeBSD systems used in the service
For non-mirrored configurations, all
.Fx
systems used in the service
are single points of failure.