Date: Sun, 29 Apr 2018 20:24:03 +0000 (UTC) From: Rick Macklem <rmacklem@FreeBSD.org> To: src-committers@freebsd.org, svn-src-projects@freebsd.org Subject: svn commit: r333093 - projects/pnfs-planb-server/usr.sbin/nfsd Message-ID: <201804292024.w3TKO38U084683@repo.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: rmacklem Date: Sun Apr 29 20:24:03 2018 New Revision: 333093 URL: https://svnweb.freebsd.org/changeset/base/333093 Log: Bring the pnfs.4 man page up to date. Modified: projects/pnfs-planb-server/usr.sbin/nfsd/pnfs.4 Modified: projects/pnfs-planb-server/usr.sbin/nfsd/pnfs.4 ============================================================================== --- projects/pnfs-planb-server/usr.sbin/nfsd/pnfs.4 Sun Apr 29 17:46:08 2018 (r333092) +++ projects/pnfs-planb-server/usr.sbin/nfsd/pnfs.4 Sun Apr 29 20:24:03 2018 (r333093) @@ -24,7 +24,7 @@ .\" .\" $FreeBSD$ .\" -.Dd July 2, 2017 +.Dd March 26, 2018 .Dt PNFS 4 .Os .Sh NAME @@ -35,69 +35,75 @@ The NFSv4.1 client and server provides support for the .Tn pNFS specification; see .%T "Network File System (NFS) Version 4 Minor Version 1 Protocol RFC 5661" . -A pNFS service separates the Read/Write operations from all other NFSv4.1 +A pNFS service separates Read/Write operations from all other NFSv4.1 operations, which are referred to as Metadata operations. The Read/Write operations are performed directly on the Data Server (DS) where the file's data resides, bypassing the NFS server. -All other operations are performed on the NFS server, which is referred to +All other file operations are performed on the NFS server, which is referred to as a Metadata Server (MDS). NFS clients that do not support .Tn pNFS perform Read/Write operations on the MDS, which acts as a proxy for the -appropriate DS. +appropriate DS(s). .Pp +The NFSv4.1 protocol provides two pieces of information to pNFS aware +clients that allow them to perform Read/Write operations directly on +the DS. +.Pp +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. +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 +is unique to the DS configuration +and changes whenever the +.Xr nfsd +daemon is restarted or the server is rebooted. +.Pp +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. +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. +.Pp +The FreeBSD client and server supports two layout types. +.Pp +The File Layout is described in RFC5661 and uses the NFSv4.1 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 +configurations. +.Pp +The Flexible File Layout allows the use of the NFSv3, NFSv4.0 or NFSv4.1 +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 +mirrored DS configurations. +The FreeBSD server supports the ``tightly coupled'' variant and all DSs use the +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 +layouts by default. +However that default can be set to the Flexible File Layout by setting the +.Xr sysctl 1 +sysctl ``vfs.nfsd.default_flexfile'' to one. +Mirrored server configurations will only issue Flexible File Layouts. .Tn pNFS clients mount the MDS as they would a single NFS server. .Pp -A +A FreeBSD .Tn pNFS client must be running the .Xr nfscbd 8 daemon and use the mount options ''nfsv4,minorversion=1,pnfs''. .Pp -A pNFS DS server must be configured as a NFSv4.1 server, where there is an -exported directory with subdirectories named ds0, ds1, ..., ds<N> created -in it. -For example, if the exported directory is /ds and the number of subdirectories is 20, the subdirectories are named -/ds/ds0, /ds/ds1, ..., /ds/ds19. -This exported directory is the one that the MDS will mount via NFSv4.1 to use as -a DS. -The subdirectories are created simply to reduce the size of the directories -by spreading the data storage files across them. -If the -.Tn pNFS -service will be storing a large number of files, the service should be -configured with a large number of subdirectories. -There really is no disadvantage in having a large number of subdirectories, -so sysadmins should err on the side of creating many of them. -Each of these subdirectories must be owned by the <user> that the -maproot -.Xr exports 5 -option maps to, since the MDS accesses these directories as <root>. -These directories should have file mode 0700, so that only the <user> mapped -for <root> has access to them. -See -.Xr exports 5 -for more information on this. -These subdirectories must be created by the sysadmin on all DS servers before -the -.Tn pNFS -service is started. -.Pp -The sysctl -.sp -.Bd -literal -offset indent -vfs.nfsd.dsdirsize -.Ed -.Pp -defines the number of subdirectories named ds0, ds1, ... , ds<N>, where N is -vfs.nfsd.dsdirsize - 1, with the default set to 20. -The number of subdirectories can be increased after the server has been -running, but only when the -.Xr nfsd 8 -daemon is not running. -.Pp When files are created, the MDS creates a file tree identical to what a single NFS server creates, except that all the regular (VREG) files will be empty. @@ -105,7 +111,6 @@ As such, if you look at the exported tree on the MDS d on the MDS server (not via an NFS mount), the files will all be of size zero. Each of these files will also have two extended attributes in the system attribute name space: -.sp .Bd -literal -offset indent pnfsd.dsfile - This extended attrbute stores the information that the MDS needs to find the data storage file on a DS for this file. @@ -114,43 +119,37 @@ pnfsd.dsattr - This extended attribute stores the Size .Ed .Pp For each regular (VREG) file, the MDS creates a data storage file on one -of the DSs, in one of the ds<N> subdirectories of the exported DS directory. +(or on each mirror for the mirrored DS case) +of the DSs which will store the file's data. The name of this file is -the file handle of the file on the MDS in hexadecimal at time of creation. +the file handle of the file on the MDS in hexadecimal at time of file creation. +The data storage file will have the same file ownership, mode and NFSv4 ACL +(if ACLs are enabled for the file system) as the file on the MDS, so that +permission checking can be done on the DS. +This is referred to as ``tightly coupled'' for the Flexible File Layout. .Pp For .Tn pNFS -clients, the service generates File Layout layouts and associated DeviceInfo. -For NFS clients that do not support NFSv4.1 pNFS, there will be a performance -hit, since the I/O RPCs will be proxied by the MDS for the DS server the -data storage file resides on. +aware clients, the service generates File Layout +or Flexible File Layout +layouts and associated DeviceInfo. +For non-pNFS aware NFS clients, the pNFS service appears just like a normal +NFS service. +For the non-pNFS aware client, the MDS will perform I/O operations on the appropriate DS(s), acting as +a proxy for the non-pNFS aware client. +This is also true for NFSv3 and NFSv4.0 mounts, since these are always non-pNFS +aware. .Pp -Configuration of a DS is done exactly as any other NFS server is configured, -with the data storage directory exported to the MDS. -.Pp -The MDS is configured to mount the data storage directories of the DSs. -For example, if there are 2 DSs named nfsv4-ds0 and nfsv4-ds1 and both of -these have a /ds directory exported to the MDS, the -.Xr fstab 5 -entries might be: -.sp +See .Bd -literal -offset indent -nfsv4-ds0:/ds /ds0 nfs rw,nfsv4,minorversion=1 0 0 -nfsv4-ds1:/ds /ds1 nfs rw,nfsv4,minorversion=1 0 0 +http://people.freebsd.org/~rmacklem/pnfs-planb-setup.txt .Ed -.Pp -The MDS will require a "-p" flag option specifying the DSs. For the above -mounts, the nfs_server_flags entry in -.Xr rc.conf 5 -might be: .sp -.Bd -literal -offset indent -nfs_server_flags="-u -t -n 256 -p nfsv4-ds0:/ds0,nfsv4-ds1:/ds1" -.Ed -.Pp -Note that the "-p" flag requires the "mounted-on" directory path on the MDS. +for information on how to set up a FreeBSD pNFS service. .Sh SEE ALSO +.Xr pnfsdscopymr 1 , .Xr pnfsdsfile 1 , +.Xr pnfsdskill 1 , .Xr nfsv4 4 , .Xr exports 5 , .Xr fstab 5 , @@ -159,7 +158,22 @@ Note that the "-p" flag requires the "mounted-on" dire .Xr nfsd 8 , .Xr nfsuserd 8 .Sh BUGS -At this time, there is no support for DS mirroring. -As such, the MDS plus all DS servers are single points of failure for the +Linux kernel versions prior to 4.12 only supports NFSv3 DSs in its client +and will do all I/O through the MDS. +For Linux 4.12 kernels, support for NFSv4.1 DSs was added, but I have seen +Linux client crashes when testing this client. +For Linux 4.17-rc2 kernels, I have not seen client crashes during testing, +but it only supports the ``loosely coupled'' variant. +To make it work correctly when mounting the FreeBSD server, you must either +patch the Flexible File Layout client driver with a patch like: +.Bd -literal -offset indent +http://people.freebsd.org/~rmacklem/flexfile.patch +.Ed +.sp +or set the sysctl ``vfs.nfsd.flexlinuxhack'' to one so that it works around +the Linux client driver's limitations. +.Pp +Since the MDS cannot be mirrored, it is a single point of failure just +as a non .Tn pNFS -service. +server is.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201804292024.w3TKO38U084683>