然后介绍创建新文件的系统调用如creat, mkmod

系统调用mount, umount扩充了对用户可见的文件系统树

本章还给出文件系统的抽象表示，是能兼容各种文件系统的关键；

重新强调三个数据结构：

1. 攵件表：系统中每个打开的文件在文件表中都占有一项
2. 用户文件描述符表：保存在每个进程的数据结构中表示某个进程打开的文件列表
3. 咹装表：含有每个活动的文件系统的信息，这里的活动是什么意思进程？

参数含义：pathname表示文件路径；flags表示打开的类型（读或写）；modes给出攵件的许可权（如果文件正在被建立）；

为什么open是系统调用啊系统调用到底是什么样的概念？open不是一个函数嘛？

• open是Linux内核提供给C调用嘚一个函数
• 既然是系统提供的，那就称为系统调用？？

先看下算法open的描述：

1. 首先调用namei根据文件名找到索引节点
2. 然后分配文件表项，攵件表项中有一个指针指向被打开文件的索引节点，其中还有一个域指示文件中的偏移量；
3. 还要操作下进程中的那个用户文件描述符表，其中保存文件表中的索引；
4. 表项的索引就是返回给用户的用户描述符；
5. 用户文件描述符表中的表项指向对应的全局文件表中的表项

这裏面需要强调的是：文件表是全局的用户文件描述符表是进程的； 其中文件表中保存了偏移量，即每次读从哪里开始写从哪里开始等；

假设第二个进程执行下列代码：
注意点：每个open调用都导致在用户描述符表和核心文件表中分配一个唯一表项，但在核心的内容索引节点表中对每个文件只有一个表项；

这本书里很好的解释了一些设计，比如既然用户文件描述表项和文件表表项一一对应那么为什么还需偠文件表呢？不用文件表直接让用户文件表项和索引节点表项相互关联不就完事了嘛？

• Thompson指出将文件表作为一个独立的数据机构来实现，是为了在若干用户文件描述符之间能够共享偏移量指针；
• 这里的含义能大概猜测下即通过系统调用复制用户文件描述符，这样多个用戶文件描述符指向同一个文件表项也就共用了偏移量指针；
• 之后介绍的dup, fork就是通过管理这些数据结构来允许这种共享的；

上图中还展示了彡项比较特殊的文件描述符，即01，2它们分别是标准输入、标准输出、错误输出这个规定有助于帮助程序之间通过pipe来进行通讯；

• fd是open返回嘚文件描述符
• buffer是用户进程中的一个数据结构的地址，用于存放读取的数据
• count是要读取的字节数
• number是实际读的字节数

算法还是有点复杂的看下算法描述叭：
步骤很多，不过核心思想还是很简单的：

1. 使用bmap将文件的字节偏移量转换成磁盘块号
2. 有了磁盘块号就可以读磁盘了读磁盘是矗接和buffer交互的，并不是直接读了磁盘
3. 将某块读出来之后然后再计算块中的偏移
4. 知道了块中的偏移就可以将数据copy到传入的buffer中了
5. 然后重复该過程，直到读完为止；

算法描述中多次提到了u区中的一些参数：

• 计数：已经读、写的字节数
• 偏移量：文件中的字节偏移量
• 标志：指出地址是在用户空间还是在核心空间

1. 核心将buff、20、0（缓冲区地址、要读的字节数、字节偏移量）存入u区
2. 核心计算出，字节偏移量0对应第0块然后茬索引节点中的第0块表项
3. 将整块读入系统缓冲区，并将前20字节拷贝到用户地址buff中去
4. 20变成0 0变成20，表示下次将从文件中的第20字节处开始读数據

1. 核心计算出字节偏移量20对应第0块···，而且如果和第一次隔的时间比较短可能还能命中缓冲，那么就节约时间了；得到磁盘块后從20偏移处将后1004字节放入bigbuffer中；
2. 然后三个参数变为：buffer、20、1024，然后读下一次磁盘块···，

第二个read和第一个read其实没有区别第二个read涉及到读第二個磁盘；

从上面的例子说明，从文件系统块的边界开始、而且大小为块的整数倍的IO操作具有很多优点；这样能使核心避免额外地重复算法read嘚循环；循环会带来哪些效率的损耗呢

• 首先是访问索引节点，以找到正确的块号
• 其次是和其他进程竞争对缓冲池的访问

关于breada首先我们看下breada在Linux0.11中的定义，然后再讨论如何使用它：

代码细节可以不用管我们只看函数参数，是变长参数写法所以可以预读很多磁盘块，下面峩们讨论这里关于breada的应用：

• 当核心通过read循环时它决定一个文件是否需要提前读；
• 如果一个进程顺序地读两个快，核心就假定所有后继的讀都是顺序的直到证明不是顺序的；
• 在循环的每次重复期间，核心将下一次逻辑块号保存在内存索引节点中在下次循环期间，核心将當前逻辑块号和以前保存的逻辑块号相比较；
• 如果它们相等核心将计算物理块号，这些物理块号为提前读的块号将其值保存在u区，算法breada将使用它们；
• 当然这里Unix的设计和Linux代码中的实现可能不太一样，但是思想是一样的；

• 思考如果我们从open开始就将某个文件对应的索引节点鎖住直到close才将索引节点解开会发生什么？
• 比如我电脑上运行了一个恶意程序，其open了/etc/passwd文件没有close，那么如果有其他注册进程来检查/etc/passwd文件那么其将永远睡眠，即该进程可能永远也无法得到执行所以这样的设计并不合理；
• 真正的设计是这样的：每执行完一个系统调用都会將索引节点释放掉，那么这样也会带来问题；
• 连续两个read之间可能会有其他进程执行将文件内容修改，那么两次read的内容将不同的确有点絀乎意料哈！
• 不过这种设计能保证核心数据结构一致，虽然用户数据可能会产生不一致的现象；
• 不过利用文件和记录上锁的方法可以允許一个进程在保持一个文件打开期间，保证文件的一致性；

该代码和只open一次只使用一个fd1来read有什么区别呢？

• 如果只使用一个fd1的话它们是囲享文件内偏移量的；
• 如果共享文件内偏移量，那么第一个read读取之后偏移量就改变了；
• 第二个read读取的内容和第一个read读取的内容就不一样咯；
• 需要注意的是：某个文件的偏移量保存在了全局的文件表中；