Linux中的文件描述符与打开文件之间的关系

1. 概述

在Linux系统中一切皆可以看成是文件,文件又可分为:普通文件、目录文件、链接文件和设备文件。文件描述符(file descriptor)是内核为了高效管理已被打开的文件所创建的索引,其是一个非负整数(通常是小整数),用于指代被打开的文件,所有执行I/O操作的系统调用都通过文件描述符。程序刚刚启动的时候,0是标准输入,1是标准输出,2是标准错误。如果此时去打开一个新的文件,它的文件描述符会是3。POSIX标准要求每次打开文件时(含socket)必须使用当前进程中最小可用的文件描述符号码,因此,在网络通信过程中稍不注意就有可能造成串话。标准文件描述符图如下:

文件描述与打开的文件对应模型如下图:

2. 文件描述限制

在编写文件操作的或者网络通信的软件时,初学者一般可能会遇到“Too many open files”的问题。这主要是因为文件描述符是系统的一个重要资源,虽然说系统内存有多少就可以打开多少的文件描述符,但是在实际实现过程中内核是会做相应的处理的,一般最大打开文件数会是系统内存的10%(以KB来计算)(称之为系统级限制),查看系统级别的最大打开文件数可以使用sysctl -a | grep fs.file-max命令查看。与此同时,内核为了不让某一个进程消耗掉所有的文件资源,其也会对单个进程最大打开文件数做默认值处理(称之为用户级限制),默认值一般是1024,使用ulimit -n命令可以查看。在Web服务器中,通过更改系统默认值文件描述符的最大值来优化服务器是最常见的方式之一,如CentOS6.6系统下的文件描述符优化:

## 查看默认文件描述符的大小
[[email protected] ~]# ulimit -n
1024

临时修改文件描述符的大小

[[email protected] scripts]# ulimit -SHn 65535
[[email protected] scripts]# ulimit -n
65535

永久修改文件描述符的大小:

[[email protected] ~]# echo ‘*               -       nofile          65535‘ >>/etc/security/limits.conf
[[email protected] ~]# tail -n1 /etc/security/limits.conf
*               -       nofile          65535

更多具体优化方式请查看http://blog.csdn.net/kumu_linux/article/details/7877770

3. 文件描述符合打开文件之间的关系

每一个文件描述符会与一个打开文件相对应,同时,不同的文件描述符也会指向同一个文件。相同的文件可以被不同的进程打开也可以在同一个进程中被多次打开。系统为每一个进程维护了一个文件描述符表,该表的值都是从0开始的,所以在不同的进程中你会看到相同的文件描述符,这种情况下相同文件描述符有可能指向同一个文件,也有可能指向不同的文件。具体情况要具体分析,要理解具体其概况如何,需要查看由内核维护的3个数据结构。

1. 进程级的文件描述符表

2. 系统级的打开文件描述符表

3. 文件系统的i-node表

进程级的描述符表的每一条目记录了单个文件描述符的相关信息。

1. 控制文件描述符操作的一组标志。(目前,此类标志仅定义了一个,即close-on-exec标志)

2. 对打开文件句柄的引用

内核对所有打开的文件的文件维护有一个系统级的描述符表格(open file description table)。有时,也称之为打开文件表(open file table),并将表格中各条目称为打开文件句柄(open file handle)。一个打开文件句柄存储了与一个打开文件相关的全部信息,如下所示:

1. 当前文件偏移量(调用read()和write()时更新,或使用lseek()直接修改)

2. 打开文件时所使用的状态标识(即,open()的flags参数)

3. 文件访问模式(如调用open()时所设置的只读模式、只写模式或读写模式)

4. 与信号驱动相关的设置

5. 对该文件i-node对象的引用

6. 文件类型(例如:常规文件、套接字或FIFO)和访问权限

7. 一个指针,指向该文件所持有的锁列表

8. 文件的各种属性,包括文件大小以及与不同类型操作相关的时间戳

下图展示了文件描述符、打开的文件句柄以及i-node之间的关系,图中,两个进程拥有诸多打开的文件描述符。

在进程A中,文件描述符1和30都指向了同一个打开的文件句柄(标号23)。这可能是通过调用dup()、dup2()、fcntl()或者对同一个文件多次调用了open()函数而形成的。

进程A的文件描述符2和进程B的文件描述符2都指向了同一个打开的文件句柄(标号73)。这种情形可能是在调用fork()后出现的(即,进程A、B是父子进程关系),或者当某进程通过UNIX域套接字将一个打开的文件描述符传递给另一个进程时,也会发生。再者是不同的进程独自去调用open函数打开了同一个文件,此时进程内部的描述符正好分配到与其他进程打开该文件的描述符一样。

此外,进程A的描述符0和进程B的描述符3分别指向不同的打开文件句柄,但这些句柄均指向i-node表的相同条目(1976),换言之,指向同一个文件。发生这种情况是因为每个进程各自对同一个文件发起了open()调用。同一个进程两次打开同一个文件,也会发生类似情况。

4. 总结

1. 由于进程级文件描述符表的存在,不同的进程中会出现相同的文件描述符,它们可能指向同一个文件,也可能指向不同的文件

2. 两个不同的文件描述符,若指向同一个打开文件句柄,将共享同一文件偏移量。因此,如果通过其中一个文件描述符来修改文件偏移量(由调用read()、write()或lseek()所致),那么从另一个描述符中也会观察到变化,无论这两个文件描述符是否属于不同进程,还是同一个进程,情况都是如此。

3. 要获取和修改打开的文件标志(例如:O_APPEND、O_NONBLOCK和O_ASYNC),可执行fcntl()的F_GETFL和F_SETFL操作,其对作用域的约束与上一条颇为类似。

4. 文件描述符标志(即,close-on-exec)为进程和文件描述符所私有。对这一标志的修改将不会影响同一进程或不同进程中的其他文件描述符

本文转自:http://blog.csdn.net/cywosp/article/details/38965239

时间: 2024-10-04 06:27:33

Linux中的文件描述符与打开文件之间的关系的相关文章

Linux中文件描述符和打开文件之间的关系

Linux中文件描述符和打开文件之间的关系 文件描述符: 在形式上是一个非负整数.实际上,它是一个索引值,指向内核为每一个进程所维护的该进程打开文件的记录表. Linux中的文件类型 Linux系统中把一切都看做文件,包括普通文件-.目录文件d.字符设备文件c.块设备文件b.符号链接文件l.文件描述符是内核为了高效管理已被打开的文件所创建的索引(一个非负整数),用于指代已被打开的文件,Linux下所有的的I/O操作的系统调用都是通过文件描述符执行.例如0表示标准输入.1表示标准输出.3表示标准错

每天进步一点点——Linux中的文件描述符与打开文件之间的关系

转载请说明出处:http://blog.csdn.net/cywosp/article/details/38965239 1. 概述 在Linux系统中一切皆可以看成是文件,文件又可分为:普通文件.目录文件.链接文件和设备文件.文件描述符(file descriptor)是内核为了高效管理已被打开的文件所创建的索引,其是一个非负整数(通常是小整数),用于指代被打开的文件,所有执行I/O操作的系统调用都通过文件描述符.程序刚刚启动的时候,0是标准输入,1是标准输出,2是标准错误.如果此时去打开一个

Unix系统编程()文件描述符和打开文件之间的关系

目前学习到的是一个文件描述符对应着一个打开的文件,似乎是一一对应的关系.但是实际上并不是这样的.多个文件描述符指向同一个打开的文件,是可能的也是必要的.这些文件描述符可以在相同或者不同的进程中打开. 要理解具体情况,需要查看内核维护的3个数据结构. 进程级的文件描述符表 系统级的打开文件表 文件系统的i-node表 针对每个进程,内核为其维护打开文件的描述符(open file descriptor)表.该表的每一条目都记录了单个文件描述符的相关信息.包括有一下信息: 控制文件描述符操作的一组标

Linux中文件描述符fd和文件指针flip的理解

转自:http://www.cnblogs.com/Jezze/archive/2011/12/23/2299861.html 简单归纳:fd只是一个整数,在open时产生.起到一个索引的作用,进程通过PCB中的文件描述符表找到该fd所指向的文件指针filp. open:文件描述符的操作(如: open)返回的是一个文件描述符(int fd),内核会在每个进程空间中维护一个文件描述符表, 所有打开的文件都将通过此表中的文件描述符来引用(fd1,fd2,fd3...); fopen:而流(如: f

文件IO详解(二)---文件描述符(fd)和inode号的关系

1.文件描述符和inode号码是不同的两个东西. 2.对于每个进程,系统会建立一个进程控制块(PCB)来保存相关的信息,而这个PCB在内核中的表现其实就是一个称为task_struct的结构体,这个结构体的成员用来保存与此进程有关的相关信息,其中有个成员是struct file_struct  *files,它是用来找到此进程所有打开的文件列表的,files变量指向的是struct file_struct类型的结构体,这个结构体中有一个成员是一个指针数组struct file *fd_array

文件描述符fd、文件指针fp和vfork()

1. fd:在形式上是一个非负整数.实际上他是一个索引值.指向kernal为每一个进程所维护的该进程打开文件的记录表. 当程序打开一个文件或者创建一个新文件的时候kernal向进程返回一个文件描述符. 优点:兼容POSIX标准,许多系统调用都依赖于它:缺点:不能移植到unix之外的系统上去 fp:FILE*指针变量标识符 优点:是C语言的通用格式,便于移植 2. vfork:使用方法同fork差不多,也适用于创建子进程 vofork特点: 1)在子进程调用exec或exit之前,它在父进程的空间

python 将文件描述符包装成文件对象

有一个对应于操作系统上一个已打开的I/O 通道(比如文件.管道.套接字等)的整型文件描述符,你想将它包装成一个更高层的Python 文件对象. 一个文件描述符和一个打开的普通文件是不一样的.文件描述符仅仅是一个由操作系统指定的整数,用来指代某个系统的I/O 通道.如果你碰巧有这么一个文件描述符,你可以通过使用open() 函数来将其包装为一个Python 的文件对象.仅仅只需要使用这个整数值的文件描述符作为第一个参数来代替文件名即可 import os fd = os.open('somefil

Unix文件系统学习笔记之二: 文件描述符、inode和打开文件表

Unix文件系统学习笔记之二: 文件描述符.inode和打开文件表 系统盘上数据的布局 文件系统无非是关于数据在磁盘上的组织以及存储空间管理的,为此,首先需要知道磁盘上数据的总体布局方式.以Unix为例,最重要的一张表如下: Unix 进程管理中和用户文件.io 最相关的数据结构:usr 数据结构 The procstructure does not record information related to file access.  However the userstructure con

[Android]文件描述符透过Binder传输的原理

在Linux中,文件描述符都是属于进程的,用整数来表示.通过fork,虽然子进程和父进程都是打开同样的文件,但文件描述符却是不同的. 同样的文件描述符值在不同进程对应不同的文件描述符值数组. 所以文件描述符透过Binder来进行传输时,不能是简单的拷贝文件描述符值. 关键是要把对应的文件结构与一个新的文件描述符对应起来,这样另一个进程和原来的进程透过不同的文件描述符对应同一个文件. 幸好,打开文件的结构struct file是可以在进程间共享的,透过进程a的文件描述符来获取struct file