文件系统，user file descriptor table, inode table, global open file table

[王晓林]

最近又回头来看UNIX文件系统，产生些新疑问。

open()被调用的时候，会影响到三张表：

1. per-process user file descriptor table（在Linux里，它是file descriptor array. [sec 12.2.6, Understanding the Linux Kernel, 3e]）
   
2. global open file table （在Linux里，这应该就是VFS里的generic file object list吧[sec 12.2.3, Understanding the Linux Kernel, 3e]）
   
3. inode table
   

这三张表都是in-core的。open()的作用就是找到该文件的inode，然后：

1. 在per-process user file descriptor table里添加一条记录，并将fd返回给调用者；
   
2. 在global open file table里也添加一条记录，主要是记录“下一次读写从什么位置（byte offset）开始”，当然还要有一个指向inode的指针；
   
3. 如果该文件是头一次被打开，那么就要把它的inode加到in-core inode table里。
   

在[sec 5.1, The Design of the Operating System]里，作者说：

The user file descriptor table entry could conceivably contain the file offset for the position of the next I/O operation and point directly to the in-core inode entry for the file, eliminating the need for a separate   kernel file table. The examples above show a one-to-one relationship between user file descriptor entries and kernel file table entries. Thompson notes, however, that he implemented the file table as a separate structure to allow sharing of the offset pointer between several user file descriptors (see page 1943 of [Thompson 78]. The dup and fork system calls, explained in Sections 5.13 and 7.1, manipulate the data structures to allow such sharing.

这比较明白地解释了为什么“下一次读写的位置”不宜放在per-process user file descriptor table里，主要是因为不方便共享。

在[sec 10.6, Modern Operating Systems, 3e]里，作者说：

 Let us consider one possible design: just put a pointer to the i-node in the file descriptor table. Although simple, unfortunately this method does not work. The problem is as follows. Associated with every file descriptor is a file position that tells at which byte the next read (or write) will start. Where should it go? One possibility is to put it in the i-node table. However, this approach fails if two or more unrelated processes happen to open the same file at the same time because each one has its own file position.

作者试图解释在inode里增加一个指针来记录某进程的“下一次读写位置”不可行。主要是说读写该文件的进程可能很多，仅靠一个指针显然行不通。

于是，我的疑问就产生了。如果仅“增加一个指针”不适用于多个进程的情况，那么多用些指针，一个指针指向一个进程的“信息”，是否可行呢？比如说就像inode中那些指向data block的指针一样，来它15个（12个直接的加上3个间接的），这样是否可行呢？

--

王晓林