文件系统之文件描述符
Linux文件系统结构
调用Open函数会发生什么
对同一个文件打开多次会怎样
父子进程的文件关系
重定向的实现
管道的实现
概述
int fd = open(pathname, flags, mode);
关于文件读取与写入，我们总是能用到open函数，返回一个文件描述符，然后就可以对fd进行操作。同样，调用socket accept函数也会返回一个fd。所以问题在于Linux是如何处理fd，使得我们可以处理真正的磁盘IO。
Linux文件系统结构
Linux文件系统表
1）进程级文件描述符表 Process File Table
2）系统级打开文件表 System File Table
3）系统i-Node表
调用Open函数会发生什么
每次open时，会在进程文件描述符表新增数据（一个int型fd 和一个指针），指针指向系统打开文件表。系统文件表会表明这个打开文件的权限（status 读、写等），当前打开文件的偏移量（offset 即下次读取时的位置），指向系统i-Node表的指针等。因此我们可以知道，fd是针对进程的概念，不同进程的相同fd很大可能并没有任何关系
对同一个文件打开多次会怎样
Process A:
fd1 = open("/var/file1", O_RDONLY);
fd2 = open("/var/file2", O_RDWR);
fd3 = open("/var/file1", O_WRONLY);
Process B:
fd1 = open("/var/file1", O_RDONLY);
fd2 = open("/var/file3", O_RDONLY);
A/B两个进程调用多次open后
不管是相同进程还是不同进程，只要调用open就会有一个新的fd和一个新的系统打开文件表的对应项，所以对这些fd进行读取操作并不会造成相互影响。因为系统文件表是独立的，offset也是独立的
父子进程的文件关系
调用fork()后
调用fork后，虽然父子进程都有独立的进程文件描述符表，但所有fd所对应的文件表都会保持完全一致，因此当我们在子进程读取fd1时，父进程的file offset也会同时变化，也就造成了一些奇怪的现象，所以对待fd的读写要谨慎处理
重定向的实现
重定向调用dup后
dup2(close_this_fd = open("my.txt", O_WRONLY), 1);
程序的输出会直接输出到标准输出，但以上语句会将现有进程的标准输出（fd = 1）重定向到my.txt对应的文件表。因此输出后，my.txt将会展示刚才程序的输出。这也就是 out > my.txt的实现
管道的实现
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
int main(void){
int pfds[2];
pipe(pfds);
if (!fork()) {
close(1); /* close normal stdout */
dup(pfds[1]); /* make stdout same as pfds[1] */
close(pfds[0]); /* we don't need this */
execlp("ls", "ls", NULL);
} else {
close(0); /* close normal stdin */
dup(pfds[0]); /* make stdin same as pfds[0] */
close(pfds[1]); /* we don't need this */
execlp("grep", "SOMETHING", NULL);
}
return 0;}
pipe管道
管道的总体原理就是（ls | grep）
1）A/B两个进程，B进程是A的子进程，A进程执行ls ，B进程执行grep
2）将A进程的标准输出通过dup2命令重定向到一个buffer区
3）B进程的标准输入通过dup2重定向到同一个buffer区
4）B进程获取到A进程的输出并执行自己的逻辑
参考文章
File System, Kernel Data Structures, and Open Files
