The relationship between file descriptors and open files in Linux

1. OverviewIn the Linux system, everything can be considered as a file, and the file can be divided into: Ordinary files, directory files, linked files and device files. File descriptor is the index created by the kernel in order to efficiently manage files that have been opened, which is a nonnegative integer (usually a small integer) used to refer to the file being opened and all system calls that perform I/O operations through the file descriptor. When the program just started, 0 is the standard input, 1 is the standard output, and 2 is the standard error. If you open a new file at this point, it will have a file descriptor of 3.The POSIX standard requires that the smallest available file descriptor number in the current process be used every time a file is opened (with a socket) , so a little attention during network communication can cause a 。 The standard file description metalized is as follows: The file description corresponds to the open file model such as: 2. File Description RestrictionsIn the writing of file operations or network communication software, beginners may generally encounter the "Too many open files" problem. This is mainly because the file descriptor is an important resource of the system, you can open as many file descriptors as you say about how much system memory you have., but in the actual implementation process, the kernel will do the corresponding processing, the general maximum number of open files will be 10% of system memory (in kilobytes) (referred to as system-level restrictions), to see the maximum number of open files at the system level can be used sysctl-a | grep fs.file-maxcommand to view. At the same time, the kernel, in order not to let a process consume all the file resources, it will be the maximum number of open files per process default processing (called User-level restrictions), the default value is generally 1024, using the Ulimit-n command can be viewed. In a Web server, optimizing the server by changing the maximum value of the system default file descriptor is one of the most common ways, such as file descriptor optimizations under the CentOS6.6 system:

# # View the size of the default file descriptor [[email protected] ~]# ulimit-n1024

Temporarily modify the size of a file descriptor

[Email protected] scripts]# ulimit-shn 65535[[email protected] scripts]# ulimit-n65535

To permanently modify the size of the file descriptor:

[Email protected] ~]# Echo ' *               -       nofile          65535 ' >>/etc/security/limits.conf [[email protected] ~]# tail-n1/etc/security/limits.conf*               -       nofile          65535

For more specific ways to optimize, see http://blog.csdn.net/kumu_linux/article/details/7877770. 3. File description conforms to the relationship between open files    Each file descriptor corresponds to an open file, and the different file descriptors point to the same file. The same files can be opened by different processes and can be opened multiple times in the same process. The system maintains a file descriptor table for each process, the value of which is 0, so in different processes you will see the same file descriptor, in which case the same file descriptor may point to the same file, or it may point to a different file. The specific situation to be specific analysis, to understand how the specific situation, you need to see the kernel maintained by the 3 data structures.     1. Process-level file Descriptor descriptor     2. System-Level Open file descriptor     3. Each entry of the file system's I-node table   process-level descriptor tables records information about a single file descriptor.     1. A set of flags that control file descriptor operations. (Currently, this type of flag only defines one, that is, the CLOSE-ON-EXEC flag)     2. References to open file handles   kernel maintains a system-level descriptor Table (open File description table) for file maintenance of all open files. Sometimes it is also called an open File table, and the entries in the table are referred to as open file handles (handle). An open file handle stores all the information associated with an open file, as shown in:    1. Current file offset (call read () and write () update, or use Lseek () to modify directly)     2. The status ID used when opening the file (that is, the flags parameter of open ()     3. File access mode (such as read-only mode, write-only mode, or read-write mode set when calling open ()     4. Signal driver-related settings     5. A reference to the file I-node object     6. File type (for example: regular file, Socket, or FIFO) and access rights     7. A pointer to the list of locks held by the file     8. The various properties of the file, including the file size and timestamps associated with different types of operations   show the relationship between file descriptors, open file handles, and I-node, in which two processes have many open file descriptors. In process A, file descriptors 1 and 30 both refer to theA handle to the same open file (label 23). This may be formed by invoking the DUP (), dup2 (), Fcntl (), or by invoking the open () function multiple times on the same file.     Process A's file descriptor 2 and Process B's File descriptor 2 all point to the same open file handle (label 73). This situation may occur after you call fork () (that is, process A, B is a parent-child process relationship), or when a process passes an open file descriptor to another process through a UNIX domain socket. And then there are different processes calling the open function on its own, the same file is opened, and the inside descriptor of the process is assigned exactly to the same descriptor as the other process opening the file.     In addition, process a descriptor 0 and process B descriptor 3 each point to a different open file handle, but these handles point to the same entry for the I-node Table (1976), in other words, to the same file. This happens because each process initiates an open () call to the same file. A similar situation can occur when the same file is opened two times with the same process.   4. Summary 1. Because of the presence of a process-level file descriptor, the same file descriptors appear in different processes, either pointing to the same file or pointing to a different file2. Two different file descriptors, if you point to the same open file handle, the same file offset will be shared.    Therefore, if you modify the file offset by one of the file descriptors (by calling read (), write (), or Lseek (), the change is observed from another descriptor, regardless of whether the two file descriptors belong to a different process or the same process.    3. To get and modify open file flags (for example: O_append, O_nonblock, and O_async), you can perform F_GETFL and F_SETFL operations of Fcntl (), which are similar to the previous one for scope constraints. 4. The file descriptor flags (that is, close-on-exec) are private to the process and file descriptors. Modifications to this flag will not affect the same process or other file descriptors in different processes this article transfers from: http://blog.csdn.net/cywosp/article/details/38965239

The relationship between file descriptors and open files in Linux