Network File System Protocol

1. Introduction
Sun's Network File System (NFS) protocol provides transparent remote access to shared files in the network. The NFS protocol is designed to be suitable for different machines, operating systems, network systems, and transmission protocols. This wide range of adaptability is achieved through the use of Remote Procedure Call (RPC) primitives built on external data descriptions (XDR. The implementation of this protocol already exists on different types of machines, such as PCs and super computers ,.

Support for the installation protocol allows the server to distribute the remote access priority to a restricted customer set. It performs specific operating system functions to allow remote directory tree links to a local file system.
1.1 Remote Procedure Call
Sun's Remote Procedure Call specification provides a process-oriented remote service interface .. Each server provides a"Program". NFS is such a program. The host address, program number, and process number combination specify a remote process. One goal of NFS is that it does not need its lower layer to provide any specific level of reliability. Therefore, it can be potentially used on many lower-layer transport layer protocols, or even on the implementation of another Remote Procedure Call. For ease of discussion, the rest of this document assumes that NFS is implemented on the RPC layer of sun.
1.2 external data description
The external data description (XDR) Standard provides a common method for describing data types on the network. The NFS protocol specification is written in the RPC data description language. For more information, see rfc1014 "XDR: external data description standard ". Despite the existence of an automated rpc/XDR compiler that can generate "stubs" for servers and clients ). NFS does not need to use them either. Any software that provides the same functions can be used. If the encoding is identical, it can also implement interoperability with other NFS implementations.

1.3 stateless Server
NFS protocol is expected to be stateless as much as possible. That is to say, the server should not have to maintain any protocol status information about its client, so that the function is correct. When a failed event occurs, the stateless server has obvious advantages over the stateful server. In a stateless server, the client only needs to resend the request until the server responds. The client does not even need to know that the server has crashed or has a temporary network failure. The client of a stateful server either needs to detect the Server failure and re-establish the server status when the server recovers, or cause the client operation to fail.

This may not sound like an important issue, but it affects the protocol in unexpected circumstances. We believe that as long as a simple server can be written, it does not need to be restored at an expensive cost after the crash, even if there are some additional complexity in the Protocol, it is worthwhile. Note: even if the so-called "reliable" transmission protocol TCP is used, the client must be able to handle the service interruption caused by re-opening the connection when they time out. Therefore, stateless protocols can simplify this implementation.

On the other hand, NFS processes files and directories as stateful objects. What are the benefits if the file does not keep its content exposed? In this way, no additional status is introduced in the Protocol itself. Inherent state operations, such as file or record locking and remote execution, are implemented as separate services and will not be discussed here.

The basic way to simplify recovery is to perform idempotent operations as much as possible (to ensure that they have the potential to be repeated ). Some operations in this Protocol Version cannot achieve this purpose; fortunately, most operations (such as read and write) are idempotent. In addition, most server failures occur between operations, rather than between operations and responses. Finally, although the failure of the server may be rare, it is difficult to distinguish the failure of any network, router or bridge from the failure of the server in a complex network.

2. NFS Protocol definition
The protocol used by the server varies over time. RPC provides a version number for each RPC request. RFC has defined two versions of the NFS protocol. Even in the second version, there are a few outdated processes and parameters, which will be deleted in later versions. RPC for the third edition of NFS Protocol is currently in preparation. (Note: This is relative to the time when the RFC document was published. This document was published on, 3)

2.1 File System Model
NFS assumes that the file system is hierarchical, except for the files at the bottom layer, and all other levels are directories. Each entry (file, directory, device, etc.) in the directory has a string name. Different operating systems may have limits on the depth of the directory tree or the name used, just as using different semantics to describe "pathnames ", it concatenates all components (directories and file names) in the name. A "File System" has a specified "root" tree on a single server (usually a disk or a physical partition. Some operating systems provide "installation" to make all file systems appear on a single tree. Other operating systems maintain a file system "Forest ". A file is a unstructured stream composed of uninterpreted bytes. NFS of the Third Edition uses a more common file system model.
NFS queries only one part of the path name at a time. Why does one get the entire path name and return a file handle? There are some reasons for not doing this. First, the path name must have a separator between the components of the path. Different operating systems use different separators. We can define a standard path representation on the network, but each path name must undergo syntax analysis and conversion at each end. Other issues are discussed in section 3 (NFS implementation issues.

Although files and directories are similar in many aspects, reading directories and reading files also require different processes. The standard network format for describing directories is provided here. Use the same parameters as above to determine a process. This process returns only one directory item each time it is called. The problem with this method is that the efficiency is not high. The directory contains many directory items. It is very slow to return each item by remote call.

2.2 server process
This Protocol is defined as a set of processes with parameters and results defined in RPC language (XDR language extensions in terms of programs, versions, and process declarations. A brief description of each process function should provide sufficient information for implementation. Section 2.3 describes the basic data types in detail.

All processes in the NFS protocol are assumed to be synchronous. When a process is returned to the client, the customer can assume that this operation has been completed, and any data related to the request is now stored in a stable storage. For example, a write request from a client may cause the server to update data blocks, file system information blocks (such as indirect blocks), and file attribute information (size and modification time ). When write is returned to the client, the client assumes that the write operation is reliable. Even when the server crashes, it can discard the written data. This is a very important part of the stateless server. If the server waits for data refresh from remote requests, the client must save these requests so that they can be sent again when the server crashes.

/*
* Remote File Service Program
*/
Programnfs_program {
Versionnfs_version {
Voidnfsproc_null (void) = 0;

Attrstatnfsproc_getattr (fhandle) = 1;

Attrstatnfsproc_setattr (sattrargs) = 2;

Voidnfsproc_root (void) = 3;

Diropresnfsproc_lookup (diropargs) = 4;

Readlinkresnfsproc_readlink (fhandle) = 5;

Readresnfsproc_read (readargs) = 6;

Voidnfsproc_writecache (void) = 7;

Attrstatnfsproc_write (writeargs) = 8;

Diropresnfsproc_create (createargs) = 9;

Statnfsproc_remove (diropargs) = 10;

Statnfsproc_rename (renameargs) = 11;

Statnfsproc_link (linkargs) = 12;

Statnfsproc_symlink (symlinkargs) = 13;

Diropresnfsproc_mkdir (createargs) = 14;

Statnfsproc_rmdir (diropargs) = 15;

Readdirresnfsproc_readdir (readdirargs) = 16;

Statfsresnfsproc_statfs (fhandle) = 17;
} = 2;
} = 100003;

2.2.1 no work

Voidnfsproc_null (void) = 0;

This process does not work. In all RPC services, it can be used to allow the server to respond to tests and timing.

2.2.2 obtain file attributes

Attrstatnfsproc_getattr (fhandle) = 1;

If the response status is nfs_ OK, the response attributes include the attributes of the file specified by the input fhandle.
2.2.3. Set file attributes
Structsattrargs {
Fhandlefile;
Sattrattributes;
};

Attrstatnfsproc_setattr (sattrargs) = 2;

The "attributes" value parameter contains fields that are either-1 or a new value of the "file" file attribute. If the response status is nfs_ OK, the response property has the file property after the "setattr" operation is complete.

Note:-1 indicates that an unused field in "attributes" will be modified in the next version of the protocol.

2.2.4 obtain the root of the file system

Voidnfsproc_root (void) = 3;

Expired. This process is no longer used, because finding the root file handle of a file system requires moving the path name between the client and the server. To do this correctly, we must define a standard network description of the path name. The root file handle query has been implemented by the mntproc_mnt process. (For details, see appendix A, "Definition of installation protocol ")

2.2.5. Query file names

Diropresnfsproc_lookup (diropargs) = 4;

If the response "status" is nfs_ OK, the response "file" and Response "attributes" are file handles and attributes of file names in the directory specified by the parameter "dir.

2.2.6 read from symbolic links

Unionreadlinkresswitch (statstatus ){
Casenfs_ OK:
Pathdata;
Default:
Void;
};
Readlinkresnfsproc_readlink (fhandle) = 5;

If the value of "status" is nfs_ OK, the response "data" is the data in the symbolic link of the file referenced by the fhandle parameter.

Note: NFS always parses the path name on the client. If different semantics is used on different clients or servers, the path name in a symbolic link may have different meanings (or meaningless ).

2.2.7 read from files

Structreadargs {
Fhandlefile;
Unsignedoffset;
Unsignedcount;
Unsignedtotalcount;
};

Unionreadresswitch (statstatus ){
Casenfs_ OK:
Fattrattributes;
Nfsdatadata;
Default:
Void;
};

Readresnfsproc_read (readargs) = 6;

In the file given by "file", "Count" bytes of "data" are returned starting from the "offset" Byte offset ". The first byte of this file is offset 0. After a read operation occurs, the file attribute is returned from "attributes.

Note: The "totalcount" parameter is not used and will be deleted in the next revision of the Protocol.

2.2.8 write to buffer zone

Voidnfsproc_writecache (void) = 7;

Will be used in the next revision of the Protocol.

2.2.9 writing to a file

Structwriteargs {
Fhandlefile;
Unsignedbeginoffset;
Unsignedoffset;
Unsignedtotalcount;
Nfsdatadata;
};

Attrstatnfsproc_write (writeargs) = 8;

Write Data from the offset byte starting with "File ". The first byte of the file is at the offset of 0. If the response status "status" is nfs_ OK, the response attribute "attributes" contains the file attributes after the write operation is complete. Write operations are atomic. The data written from this write operation will not be mixed with the data written by another write operation on the client.

Note: The "beginoffset" and "totalcount" parameters are ignored and will be deleted in the next revision of the Protocol.

2.2.10 create a file

Structcreateargs {
Diropargswhere;
Sattrattributes;
};

Diropresnfsproc_create (createargs) = 9;

The file "name" is created in the directory specified by "dir. The initial attribute of the new file is determined by "attributes. The response status of nfs_ OK indicates that the file has been created. The response "file" and Response "attributes" are the file handle and attributes of the file. Any other response status "status" means this operation fails and no file is created.

Note: This routine can pass the creation flag of a row, which means "create this file only when the file does not exist ".

2.2.11 delete an object

Statnfsproc_remove (diropargs) = 10;

The file "name" is deleted from the directory identified by "dir. The nfs_ OK response indicates that the directory item is deleted.

Note: operations may not be idempotent.

2.2.12 rename a file

Structrenameargs {
Diropargsfrom;
Diroparsto;
};

Statnfsproc_rename (renameargs) = 11;

In the "from. dir" directory, the "from. Name" file is renamed as the file name "to. Name" in the "to. dir" directory ". If the response is nfs_ OK, the file is renamed. The RENAME operation is an atomic operation on the server; it cannot be interrupted during execution.

Note: operations may not be idempotent.

2.2.13 create a file link

Process 12, version 2.

Structlinkargs {
Fhandlefrom;
Diroparsto;
};

Statnfsproc_link (linkargs) = 12;

Create the file "to. Name" in the "to. dir" Directory, which is a hard link to the existing file "from. If the returned value is nfs_ OK, a link is created. If other values are returned, this link is not created.

A hard link should have this attribute. Any change in the linked file will affect the two files. When a hard link points to a file, the file attribute should have a value indicating "nlink", which is larger than the value before the link.

Note: operations may not be idempotent.

2.2.14 create a symbolic link

Structsymlinkargs {
Diropargsfrom;
Pathto;
Sattrattributes;
};

Statnfsproc_symlink (symlinkargs) = 13;

In the specified directory "from. dir", create a file with the nflnk type "from. Name ". This new file contains the path name "to" and has the initial attribute specified by "attributes. If the returned value is nfs_ OK, a link is created. Any other returned values indicate an error. The link is not created.

A symbolic link is a pointer to another file. The name given in "to" is not interpreted by the server and is only stored in the new file. When the client references a symbolic link file, the content in the symbolic link is often re-interpreted as a replacement path name. The readlink operation returns the data to be interpreted by the client.

Note: On Unix servers, attributes is never used because symbolic links always have a 0777 pattern.

2.2.15 create a directory

Diropresnfsproc_mkdir (createargs) = 14;

The new directory "where. Name" is created in the specified directory "where. dir. The initial attribute of the new directory is determined by "attributes. The returned value of an nfs_ OK statement indicates that the new directory is created. The response "file" and Response "attributes" indicate the file handle and attributes of the new directory. If any other response status "status" is returned, the operation fails and no directory is created.

Note: operations may not be idempotent.

2.2.16 delete a directory

Statnfsproc_rmdir (diropargs) = 15;

The empty directory "name" in the directory specified by "dir" will be deleted. If the response is nfs_ OK, the directory will be deleted.

Note: operations may not be idempotent.

2.2.17 read from the directory

Structreaddirargs {
Fhandledir;
Nfscookiecookie;
Unsignedcount;
};

Structentry {
Unsignedfileid;
Filenamename;
Nfscookiecookie;
Entry * nextentry;
};

Unionreaddirresswitch (statstatus ){
Casenfs_ OK:
Struct {
Entry * entries;
Booleof;
} Readdirok;
Default:
Void;
};

Readdirresnfsproc_readdir (readdirargs) = 16;

Returns a set of variable target directory items from the directory specified by "dir". The total size is "count" bytes. If the returned status value "status" is nfs_ OK, it is followed by a group of variable "entries ". Each "entry" contains a "fileid", which is the number uniquely identified by the file system, the file name and an opaque Pointer "cookie" pointing to the next directory item in the directory. The cookie is used in the following readdir call to obtain more directory items from a specified start point in this directory. The special cookie value 0 (all bits are 0) allows you to obtain directory items from the beginning of the directory. The "fileid" field should have the same value as the "fileid" field in the file property. (See Section 2.3.5 "fattr" in "Basic Data Type".) If there are no more directory items in the directory, the value of the "EOF" flag is true.

2.2.18 obtain file system attributes

Unionstatfsres (statstatus ){
Casenfs_ OK:
Struct {
Unsignedtsize;
Unsignedbsize;
Unsignedblocks;
Unsignedbfree;
Unsignedbavail;
} Info;
Default:
Void;
};

Statfsresnfsproc_statfs (fhandle) = 17;

If the response status "status" is nfs_ OK, the response "info" gives the file system attributes that contain the file referenced by the input file handle fhandle. Attribute fields contain the following values:

Tsize indicates the Optimal Transmission size in bytes. This is the server's Read and Write Request
The maximum number of data bytes.

The size of the bsize File System in bytes ..

The total number of bsize blocks in the blocks file system.

The number of free "bsize" blocks in the bfree file system.

The number of "bsize" blocks available for the bavail unprivileged user.

Note: If the file system has a variable-Size Block, this call cannot work well.

2.3 Basic Data Types
The following XDR definitions are the basic structures and types used to describe other structures.

2.3.1.stat (Statistical type)

Enumstat {
Nfs_ OK = 0,
Nfserr_perm = 1,
Nfserr_noent = 2,
Nfserr_io = 5,
Nfserr_nxio = 6,
Nfserr_acces = 13,
Nfserr_exist = 17,
Nfserr_nodev = 19,
Nfserr_notdir = 20,
Nfserr_isdir = 21,
Nfserr_fbig = 27,
Nfserr_nospc = 28,
Nfserr_rofs = 30,
Nfserr_nameconlong = 63,
Nfserr_notempty = 66,
Nfserr_dquot = 69,
Nfserr_stale = 70,
Nfserr_wflush = 99
};

The statistical type "stat" is returned in the call results of each process. The value of nfs_ OK indicates that the call is successful and the result is valid. Other values indicate some errors generated by the server side in the process service. These error values come from UNIX error numbers.

Nfserr_perm
The caller is not the correct owner of the requested operation.

Nfserr_noent
This file or directory does not exist. The specified file or directory does not exist.

Nfserr_io
A hardware error occurs during Operation execution. For example, this may be a disk error.

Nfserr_nxio
There is no such device or address.

Nfserr_acces
The permission is denied. The caller does not have the correct permission to perform the request.

Nfserr_exist
File exists. The specified file already exists.

Nfserr_nodev
There is no such device.

Nfserr_notdir
Not a directory. In the directory operation, the caller specifies a non-directory.

Nfserr_isdir
Is a directory. The caller specifies a directory in a non-directory operation.

Nfserr_fbig
The file is too large. Operation causes file growth to exceed the server limit.

Nfserr_nospc
There is no available space on the device. This operation causes the Server File System to reach its limit.

Nfserr_rofs
Read-Only file system. Try to write in a read-only file system.

Nfserr_namw.long
The file name is too long. The file name is too long in the operation.

Nfserr_notempty
The directory is not empty. Try to delete a non-empty directory.

Nfserr_dquot
The disk quota is exceeded. The disk quota of the customer on the server has exceeded.

Nfserr_stale
The file handle "fhandle" in the parameter is invalid. That is to say, the file referenced by the file handle no longer exists.
Or the access settings have been revoked.

Nfserr_wflush
Use the server write buffer in the "writecache" call to refresh the disk.

2.3.2.ftype (file type)

Enumftype {
Nfnon = 0,
Nfreg = 1,
Nfdir = 2,
Nfblk = 3,
Nfchr = 4,
Nflnk = 5
};

The enumerated "FTYPE" type indicates the file type. The nfnon type indicates that it is not a file, nfreg indicates a normal file, and nfdir indicates a directory. Nfblk indicates a specific block device, nfchr indicates a specific character device, and nflnk indicates a symbolic link.

2.3.3.fhandle (file handle)

Typedefopaquefhandle [fhsize];

"Fhandle" is a file handle transmitted between the server and the client. All file operations use a file handle to reference a file or directory. The file handle contains the information required by the server to distinguish a single file.

2.3.4.timeval (Time Value)

Structtimeval {
Unsignedintseconds;
Unsignedintuseconds;
};

The "timeval" structure is a second and microsecond value, starting from the early morning of January 1, January 1, 1970 GMT. It is used in the information of the transfer time and date.

2.3.5.fattr (file attributes)

Structfattr {
Ftypetype;
Unsignedintmode;
Unsignedintnlink;
Unsignedintuid;
Unsignedintgid;
Unsignedintsize;
Unsignedintblocksize;
Unsignedintrdev;
Unsignedintblocks;
Unsignedintfsid;
Unsignedintfileid;
Timevalatime;
Timevalmtime;
Timevalctime;
};

The "fattr" structure contains the file attributes; "type" indicates the file type; "nlink" indicates the number of hard links of a file (the number of different names of the same file ); "uid" is the user ID number of the owner of the file; "gid" is the group ID number of the group that owns the file; "size" is the size of the file measured in bytes; "blocksize" indicates the size of a block in the file in bytes. If the file type is nfchr or nfblk, "rdev" indicates the device Number of the file; "blocks" indicates the number of blocks on the disk. "fsid" indicates the system identifier of the file system that contains the file; "fileid" is the unique identifier Number of the file in its file system. "atime" is the last time the file was read or written; "mtime" indicates the time when the file data was last modified (write); "ctime" indicates the time when the file status was last changed. If the file size changes, writing a file also changes "ctime ".

"Mode" is the access mode encoded into a bit set. Note that the file type is either specified in the mode bit or in the file type. This is actually a defect in this agreement and will be revised in future versions. The following description uses the octal number to determine the bit location

0040000 this is a directory, and the "type" field should be nfdir.
0020000 this is a special character file. The "type" field should be nfchr.
0060000 this is a special block file. The "type" field should be nfblk.
0100000 this is a normal file. The "type" field should be nfreg.
0120000 this is a symbolic link file. The "type" field should be nflnk.
0140000 this is a named socket; the "type" field should be nfnon.
0004000 set the user ID in execution
0002000 set the ID of the Group in execution
0001000 Save the exchanged text after use.
0000400 read permission to the owner.
0000200 write permission for the owner.
0000100 permit the owner to execute and search.
0000040 read permission for the group.
0000020 write permission for a group.
0000010 grant the group execution and search permissions.
0000004 read permission for others.
0000002 write permission for others.
0000001 permission to execute and search for others.

Note: These bits are the same as those returned by the stat (2) System Call in UNIX. File Type
In the pattern bit, either the file type is determined. This will be modified in future versions.

In the property structure, the "rdev" field is the identifier of an operating system-specific device. Under this protocol
The version will be deleted.

2.3.6.sattr (set file attributes)

Structsattr {
Unsignedintmode;
Unsignedintuid;
Unsignedintgid;
Unsignedintsize;
Timevalatime;
Timevalmtime;
};

The "sattr" structure contains the attributes of files that can be set from the client. These fields have the same meaning as the above "fattr" fields. If the value of "size" is 0, the file will be truncated. A value of-1 indicates that this field is ignored.
2.3.7.filename (file name)

Typedefstringfilename <maxnamlen>;

"FILENAME" is used to transmit the components of a file name or path name.

2.3.8.path)

Typedefstringpath <MAXPATHLEN>;

"Path" is a path name. The server uses it as a string without an internal structure, but for the client, it is the name of the node in the file system tree.

2.3.9.attrstat (attribute status)

Unionattrstatswitch (statstatus ){
Casenfs_ OK:

Fattrattributes;
Default:
Void;
};

The "attrstat" structure is a common process result. It contains a "status". If the call is successful, it also contains the attributes of the operation acting on that file.

2.3.10.diropargs (directory operation parameters)

Structdiropargs {
Fhandledir;
Filenamename;
};

The "diropargs" structure is used in Directory attribute operations. "Dir" is the directory in which the file "name" is searched. A directory operation affects this directory.

2.3.11.diropres (directory operation result)

Uniondiropresswitch (statstatus ){
Casenfs_ OK:
Struct {
Fhandlefile;
Fattrattributes;
} Diropok;
Default:
Void;
};

Return the result of the Directory operation in "diropres. If this call is successful, the new file handle "file" and File Attribute "attributes" related to this file will be returned together with "status.

3. Problems in NFS implementation
The NFS protocol is designed to allow different operating systems to share files. However, because it is designed in a Unix environment, many operations are similar to the operation semantics of UNIX file systems. This section discusses specific details and semantics in implementation.

3.1 Relationship between servers and clients
The NFS protocol is designed to make the server as simple and universal as possible. Sometimes, if the client wants to implement complex file system semantics, the simplicity of the server may be a challenge.

For example, some operating systems allow you to delete open files. A process can open a file and delete it from the directory when the file is opened. As long as the process keeps the file open, the file can be read and written, even if the file has no name in the file system. For stateless servers, implementing these semantics is impossible. The client can use some tips, such as renaming the file during deletion and deleting it only when it is disabled. We believe that the server provides sufficient functionality to implement the semantics of most file systems on the client.

Each NFS client is also a potential server. Remote and locally installed file systems can be freely mixed. When the client browses the directory tree of the Remote File System and reaches the Installation Point of another remote system on the server, some interesting problems may occur. To allow the server to follow the second Remote Installation, You need to perform cyclic detection, and the server search and user will take effect again. Instead, we decided not to let the client go beyond the server's Installation Point .. When the client queries the directory where the file system has been installed on a server, the client will see the following directory instead of the installed directory.

For example, if the server has a file system named "/usr", install another file system on "/usr/src". If the client has installed "/usr ", it will not see the installation version of "/usr/src. The client can perform remote installation to maintain the server view with the Server Installation points. In this example, the client should install "/usr" in addition to "/usr/src", even if they are from the same server.

3.2 path name resolution
The parsing rules of path names on the client are always complicated. For example, symbolic links can have different interpretations on different clients. Another common problem for non-Unix implementations is that the specific explanation of the path ".." is the parent directory of the given directory. The next revision of this protocol will use a clear flag to indicate the parent directory.

3.3 licensing issues
Strictly speaking, the NFS protocol does not define the server permission check. However, you also want to use auth_unix type authentication as the basic protection machine to create a normal operating system permission check, the server gets the valid "uid" of the customer ", valid "gid" and the Group on each call, use them to check the license. The problems generated by using this method can be solved in some interesting ways.

Using "uid" and "gid" implies that the client and server share the same "uid" list. Each server and client must have the same user to the "uid" and group to the "gid" ing. Because each client may also be a server, this means that the entire network shares the same "UID/GID" space. Auth_des (the next revision of the NFS protocol) uses strings to replace numbers, but there are still complicated problems to solve.

Another problem occurs because the open operation is stateful. Most operating systems check the permission when opening a file, and check whether the file is opened during each read/write request. In a stateless server, the server cannot know whether the file is opened. You must check the permission for each read/write call. On a local file system, you can open a file and change its permissions to prevent others from accessing it. However, you can still write files because the file is open. On the contrary, the write operation fails on the remote file system. To avoid this problem, check the server licenseAlgorithmThe file owner is allowed to access the file regardless of the license settings.

Similar problems also occur when page scheduling is performed on files in the network. Before opening a file for page scheduling, the operating system always checks the execution permission and reads the block from the opened file. The file may not have the read permission, but this is not a problem after the file is opened. The NFS server cannot distinguish between normal file read and page call request read. To make this work, if the "uid" given in the call has the execution or read permission on the file, the server will allow the file to be read.

In most operating systems, a special user (on UNIX, the user ID is 0) has the permission to access all files, regardless of the ownership of the files and the Set permission. "Super-user" permissions cannot be allowed on the server, because anyone with super-user permissions on their workstation can access all remote files. Before the access check, the Unix server maps user id0 to-2 by default. This is an exception in the NFS root file system, where superuser access is unavoidable.
3.4rpc Information
Authentication
The NFS service uses auth_unix, auth_des, or auth_short type authentication,
In the case of null, auth_none is also allowed.

Transmission Protocol
NFS is generally supported by UDP.

Port Number
The NFS protocol currently uses the UDP port number 2049. This is not a officially assigned port number. Therefore,
Later versions of this Protocol use the "port ing" tool of RPC.
3.4xdr structure size
Here are some sizes that use different XDR structures in this Protocol, which are given in decimal bytes.

/*
* Maximum number of bytes of data in a read/write request.
*/
Constmaxdata = 8192;

/* Maximum number of bytes in the path parameter */
Constmaxpathlename = 1024;

/* Maximum number of bytes in the file name parameter */
Constmaxnamlen = 255;

/* The size of the "cookie" bytes transmitted by readdir */
Constcookiesize = 4;

/* Size of the number of bytes of the opaque file handle */
Constfhsize = 32;
3.6 set RPC Parameters
Different file system parameters and options should be set during installation. The installation protocol is described in the Appendix. For example, a "soft" installation is also provided like a "hard" installation. When the RPC operation fails (after a retransmission option number is provided), the soft Installation File System returns an error, while the hard installation file system continues to re-upload. The maximum transfer size depends on the implementation. Generally, 8192 bytes of data is used for an effective operation on the Internet. This may cause lower-layer segmentation (such as at the IP layer ). Since some network interfaces do not allow such packages, 512 or 1024 bytes always provide better results for operations on low-speed networks, hosts, or through gateways.

The client and server may need to save the current operation in the buffer to help avoid problems caused by non-idempotent operations. For example, if the transport protocol loses the response to the delete file operation, the server may return an nfserr_noent to replace nfs_ OK during retransmission. However, if the server maintains the operation and result of the last request, it may return the correct successCode. Of course, servers may crash and restart during retransmission. However, a small buffer (or even only one entry) will solve most of the problems.

Appendix A definition of the installation protocol
A.1. Introduction
The installation protocol is separated from the NFS protocol, but is related to the NFS protocol. It provides a service specific to the operating system to extend the NFS function: query the server path name, make the user's identity valid, and check the access permission. The client obtains the first file handle using the installation protocol, which allows the client to access a remote file system.

The installation protocol is separated from the NFS protocol, making it easy to add new access check and validation methods without changing the NFS server protocol.

Note: The definition of this Protocol implies that the server is stateful, because the server maintains a list of Client installation requests. The installation list information is not harmful to the functions of the client or server. It is only recommended to give possible warnings to the client when the server fails.

The first version of the installation protocol is used together with the second version of the NFS protocol. The only communication information between the two Protocols is the "fhandle" structure.
A.2rpc Information
Authentication
The installation service only uses auth_unix and auth_none authentication.

Transmission Protocol
The installation service is supported by UDP and TCP.

Port Number
Negotiate with the port er of the server to find the port number registered by the installation service.
A.3xdr structure size
Here we use the sizes of different XDR structures in this Protocol, expressed in decimal.

/* Maximum number of bytes of the path name parameter */
Constmntpathlename = 1024;

/* Maximum number of bytes of a name parameter */
Constmntnamlen= 255;

/* Number of bytes of the opaque file handle */
Constfhsize = 32;
A.4 Basic Data Type
This section describes the data types used in the installation protocol. In many cases, they are similar to the data types used in NFS.

A.4.1.fhandle

Typedefopaquefhandle [fhsize];

The "fhandle" type is the file handle that the server sends to the client. All file operations use file handles to reference files or directories. The file handle contains the information required by the server to distinguish a single file.

This is the same as the definition of "fhandle" XDR in NFS Protocol version 2. See "2.3.3.fhandle" in "basic data type ".
A.4.2.fhstatus

Unionfhstatusswitch (unsignedstatus ){
Case0:
Fhandledirectory;
Default:
Void;
}

The "fhstatus" type is a union structure. If the returned "status" is 0, the call is successful, followed by the file handle allocated to "directory. A non-zero value indicates some types of errors. In this case, status is a UNIX error code.
A.4.3.dirpath

Typedefstringdirpath <mntpathlen>;

The "dirpath" type is the path name of a directory server.
A.4.4.name

Typedefstringname <mntnamlen>;

The "name" type is a binary string used in different names.
A.5. server process
The following section defines the RPC process provided by the Installation server.

/*
* Protocol definition of the installer
*/
Programmountprog {
/*
* The first version of the installation protocol is used together with the second version of the NFS protocol.
*/
Versionmountvers {

Voidmountproc_null (void) = 0;

Fhstatusmountproc_mnt (dirpath) = 1;

Mountlistmountproc_dump (void) = 2;

Voidmountproc_umnt (dirpath) = 3;

Voidmountproc_umntall (void) = 4;

Exportlistmountproc_export (void) = 5;
} = 1;
} = 100005;
A.5.1. no work

Voidmntproc_null (void) = 0;

This process does nothing. It is used in all RPC services to allow the server to respond to tests and timing.
A.5.2 add installation entry
Fhstatusmntproc_mnt (dirpath) = 1;

If the response status "status" is 0, the response "directory" contains the file handle of the directory "dirname. This file handle may be used in the NFS protocol. This process also adds a new project to the "dirname" installation list installed by the customer.

A.5.3 return the installation entry

Struct * mountlist {
Namehostname;
Dirpathdirectory;
Mountlistnextentry;
};

Mountlistmntproc_dump (void) = 2;

Returns a list of remote file systems. "Mountlist" contains an entry for each pair of "hostname" and "directory.
A.5.4. Delete the installation entry

Voidmntproc_umnt (dirpath) = 3;

Delete the installation list entry from input "dirpath"
A.5.5. Delete All installation entries
Voidmntproc_umntall (void) = 4;

Delete all installation list entries for the client
A.5.6. back to output list
Struct * groups {
Namegrname;
Groupsgrnext;
};

Struct * exportlist {
Dirpathfilesys;
Groupsgroups;
Exportlistnext;
};

Exportlistmntproc_export (void) = 5;

Returns a set of output list entries for a variable. Each entry contains the file system name and a list of groups that can be imported. The file system name is in "filesys", and the group name is in "groups.

Note: The output list should contain more information about the file system status, such as the read-only flag.

Author address
Billnowicki
Sunmicrosystems, Inc.
MailStop1-40
2550 garciaavenue
Mountainview, ca94043

Phone :( 415) 336-7278

Email: nowicki@SUN.COM