Introduction to Sun's Network File System

1 Introduction (Introduction)

The famous Sun Company designed and developed NFS (Network File System) in 1984 ). NFS provides transparent access to remote files for client programs and features unrelated to the operating system platform. NFS is the first product to provide distributed file services. Its design and implementation have been successful in both technology and business. It is widely used in industrial and academic fields.

Characteristics)

L access transparency)
The NFS client component provides the same APIs as the local operating system for local processes. In this way, you can access remote files correctly without modifying existing programs.

L location transparency)
Each client installs directories in the remote file system to a local namespace to create a namespace. With proper configuration, each client can establish an independent namespace to achieve location transparency.

L mobility transparency)
The file system can be migrated between servers, but the Remote Installation table of each client must be updated independently. Therefore, NFS does not fully implement migration transparency.

L fault transparency (fault tolerance)
The stateless and idempotence of the NFS file access protocol ensures that the Remote File Error Mode observed by the client is similar to that observed by the local file. Client user-level processes and client computer faults have no impact on the server.

L consistency)
NFS provides some primitives similar to one-copy to meet the needs of most applications. However, it is not recommended to use NFS for file sharing for communication and other closely related operations on different computers.

L Security)
By integrating Kerberos, the secure RPC mechanism is used to ensure the security of user identification and data transmission.

L Efficiency)
The cache technology is used on both the server and client to achieve high efficiency.

3. Design and Implementation 3.1 NFS Architecture)

Figure 2.1 NFS Architecture

The NFS server component resides in the kernel of each NFS server computer. When an application needs to access a remote file system, the NFS client component captures the request, translates the request into an NFS operation, and passes it to the NFS server component of the remote computer. The NFS client component communicates with the server component through a remote process call. Sun's RPC system is specially developed for NFS. It supports both UDP and TCP Protocols through configuration, while NFS is compatible with both. Figure 2.1 shows the overall architecture of NFS. The following describes the specific implementation of NFS.

3.2 Virtual File System)

The Virtual File System is designed to achieve access transparency and eliminate the differences between user programs on local and remote file operations. As shown in 2.1, other distributed file systems that support UNIX calls can also be integrated through the VFS component. The VFS component can distinguish between local files and remote files, and provides a unified interface for upper-level system calls to eliminate inconsistency between the two. Then, based on the saved file information, send a file access request to a local UNIX file system, NFS client component, or another file system.

3.3 client Integration)

The NFS client component imitates the standard UNIX File System primitive and is integrated with the Unix kernel to provide some suitable interfaces for common applications. Because client components are integrated with the kernel rather than provided as a library, user programs can access files through UNIX calls without re-Compiling and loading; by using shared cache recently used blocks, a single client component can provide services for all user-level processes. Keys sent to the service period to identify users can be kept in the kernel to prevent user-level customers from stealing. The client component works together with the virtual file system. Its role is similar to that of the UNIX file system, but it is responsible for the transfer of files on the server and applications.

3.4 access control and authentication (access control and Authentication)

Unlike a Common Unix File System, the NFS server adopts statelss to facilitate fault recovery, and does not keep the file open for the client. Therefore, for each request, the server checks the user's identity to prevent unauthorized access. Sun's RPC Protocol requires each client to send user identification information (for example, a common UNIX 16-bit user ID and group ID) for each request ). The NFS server provides RPC interfaces to all processes on public ports. This access control mechanism is simple, but it also brings about security vulnerabilities. The client can modify the RPC call without the user's permission, including the user's ID for illegal access. To disable this vulnerability, You can encrypt the user identification information in the RPC protocol. Recently, Kerberos has been integrated with NFS to provide a more comprehensive solution for user identification and security issues.

3.5 NFS server interface (NFS server interface)

The NFS server interface is a set of RPC interfaces provided by the NFS server. It also includes flat file service and Directory Service ):

L common file service
Read (FH, offset, count)
Write (FH, offset, Count, data )-
Getattr (FH)
Setattr (FH, ATTR)

L Directory Service
Lookup (dirfh, name)
Create (dirfh, name, ATTR)
Remove (dirfh, name)
Rename (Dir, name, todirfh, toname)
Link (newdirfh, newname, FH)
Symlink (newdirfh, newname, string)
Readlink (FH)
Mkdir (dirfh, name, ATTR)
Rmdir (dirfh, name)
Readdir (dirfh, Cookie, count)
Statfs (FH)

3.6 Mount Service)

To install a remote file system on a client, a user-level installation process running on an NFS server computer is required. The file/etc/exports on each server contains the name of the local file system that can be remotely installed, and each file system name has an access list associated with it, specifies the host that allows the file system to be installed.

3.7 cache mechanism (caching)

To improve the performance, NFS also uses the server-side cache and client-side cache technologies. The following briefly introduces the two technologies.

3.7.1 server Cache)

The NFS server uses the same cache as other files. Using the server's cache for recent reads to obtain disk blocks will not cause consistency issues. If the server performs write operations, you need to take measures to ensure that even if the server fails, the client should be able to ensure that its data is not lost. In NFS 3rd, write operations provide two options:

L cache the data in client write operations in the server's cache and write the data to the disk between the reply clients. This is called the write-through technology, so that the client can ensure that its data has been permanently saved.

L The data in the write operation is only saved in the cache. Write the file to the disk only when you receive the request from the client for submitting the file. When the client receives a response to the submitted operation, it is sure that its data has been permanently saved. The standard NFS client adopts this operation mode.

3.7.2 Client Cache)

To reduce the number of requests sent, the NFS client component caches the returned results of read, write, getattr, lookup, and readdir operations. Using the Client Cache Technology, the write operation results cannot immediately update the file copies cached by other clients. To solve this problem, NFS introduces a timestamp mechanism. Each data or metadata item in the cache is labeled with two timestamps: TC indicates the latest effective time of the cache entry, and TM indicates the last modified time of the server data block. Set the refresh interval to T. If the (t-tc <t) V (tmclient = tmserver) condition is true, the cache entries are valid at the t time. T is set based on the file update speed, and the consistency and validity are weighed.