[OS] mmap | fd是什么 | inode机制 | vfs封装

Linux 下一切皆文件
  * 统统抽象为文件，体系封装一层布局体之后，通过指针来访问
  * 文章背面的 几个思索题都挺好的
  * 背面涉及到的inode 机制，去年暑假的这篇文章，有详细的记录到过
  【Linux】(26) 详解磁盘与文件体系：从物理布局到inode机制
  

prompt1

先容 mmap的信息，这是一个Unix-like操纵体系中的体系调用，用于将文件或装备映射到内存。

---

mmap（Memory Map）是一种内存映射技能，主要用于将文件或装备直接映射到进程的虚拟地点空间，使进程可以像操纵内存一样读写文件，从而制止频繁的体系调用（如read/write）。以下是其焦点要点：
1. 焦点原理

• 虚拟内存映射：通过创建文件磁盘地点与进程虚拟地点的对应关系，实现文件内容与内存的直接交互。操纵体系负责管理虚拟内存与物理存储的映射及数据同步（如脏页回写）CITE_
  
• 按需加载：文件内容并非一次性全部加载到物理内存，而是通太过页机制，仅在实际访问时加载所需部分
  

2. 主要用途

• 文件高效读写：减少数据拷贝次数（传统read/write需两次拷贝，mmap只需一次），提升大文件或高频访问场景的性能
  
• 进程间通信（IPC）：多个进程映射同一文件到内存，实现共享内存通信 。
  
• 内存管理优化：如MongoDB的MMAP存储引擎，将数据文件映射到内存，由操纵体系管理内存换页
  

3. 工作模式

• 文件映射：将磁盘文件映射到内存，支持MAP_SHARED（修改同步到文件）和MAP_PRIVATE（写时复制，修改不同步）
  
• 匿名映射：创建初始化为零的内存区域，用于进程间共享数据（需指定MAP_ANONYMOUS）
  

4. 函数原型

1. void *mmap(void *addr, size_t length, int prot, int flags, int fd, off_t offset);

复制代码

• 关键参数：
  

• 
  
  
  
  • prot：内存保护（如PROT_READ/PROT_WRITE）。
    
  • flags：映射范例（如MAP_SHARED/MAP_PRIVATE）。
    
  • fd：文件描述符（匿名映射时设为-1）
    
     
  

5. 优势与场景

• 优势：减少用户态与内核态切换开销，提升IO效率；简化内存与文件的一致性管理。
  
• 典范场景：高频小数据读写、大文件处理、跨进程数据共享、数据库存储引擎
  

附：内存映射流程表示图

1. id: mmap-flow
2. name: mmap工作流程
3. type: mermaid
4. content: |-
5.   graph LR
6.     A[进程调用mmap] --> B[内核创建VMA映射]
7.     B --> C[访问虚拟地址触发缺页中断]
8.     C --> D[加载文件数据到物理内存]
9.     D --> E[进程直接操作内存]
10.     E --> F[内核同步脏页到文件]

复制代码

---

prompt2:

在一个进程当中实行a.out步伐，在映射共享区域的部分如果说a.out步伐与共享对象链接，比如说标准C库当中的Libc，那么这些对象都是动态链接到这个库，然后在映射到用户虚拟地点空间当中的共享区域。我想问的是共享区域是指的相同的物理内存，那他们在共享LibC的时间，各个进程之间的虚拟地点可能也是不一样的，那这些不一样的虚拟地点它的分配机制是什么

---

在操纵体系中，当多个进程通过动态链接共享标准C库（如libc）时，这些进程的虚拟地点空间中的共享区域映射到相同的物理内存，但各自的虚拟地点可能不同。这种机制通过以下关键点实现：

---

1. 动态链接与共享对象加载

• 动态链接器（ld.so）：负责加载共享库（如libc.so）到进程的虚拟地点空间。动态链接器会在进程启动时解析共享库的依靠关系，并通过mmap体系调用将共享库映射到进程的虚拟地点空间中的Memory Mapping Segment区域
  
• 地点空间布局随机化（ASLR）：现代操纵体系默认启用ASLR，共享库的虚拟地点在每次加载时会被随机化，以提高安全性。因此，不同进程中同一共享库的虚拟地点通常不同
  

---

2. 共享区域的物理内存映射

• 物理内存共享：共享库的代码段（.text）和数据段（.data、.rodata）在物理内存中仅保留一份副本。全部进程的页表会将各自的虚拟地点映射到这些物理页，从而实现内存共享
  
• 写时复制（COW）：对于可写的共享库数据段（如全局变量），初始时全部进程共享同一物理页。当某个进程尝试修改数据时，会触发COW机制，为该进程创建私有副本，但代码段仍保持共享
  

---

3. 虚拟地点分配机制

• 动态链接器的地点选择：动态链接器在加载共享库时，会根据进程虚拟地点空间的空闲区域选择符合的位置。例如，在32位Linux体系中，共享库通常映射到0x40000000附近的区域；在64位体系中，可能映射到0x7f0000000000附近
  
• 位置无关代码（PIC）：共享库编译为位置无关代码（通过-fPIC选项），使得代码可以在任意虚拟地点运行，无需重定位绝对地点。这答应不同进程将同一共享库映射到不同的虚拟地点
  

---

4. 进程虚拟地点空间的管理

• 独立页表：每个进程维护独立的页表，记录虚拟地点到物理地点的映射关系。即使两个进程的共享库虚拟地点不同，页表也能将它们映射到相同的物理内存
  
• 内存映射区域（Memory Mapping Segment）：共享库、文件映射和匿名映射均位于此区域。该区域的虚拟地点范围通常在堆和栈之间，详细位置由操纵体系动态分配
  

---

5. 示例：libc的加载过程

• 进程启动：实行a.out时，动态链接器ld.so被加载到进程的虚拟地点空间。
  
• 加载libc.so：ld.so通过mmap将libc.so的代码段和数据段映射到进程的Memory Mapping Segment区域。
  
• 地点分配：若ASLR启用，libc.so的基地点随机化；否则使用默认地点。
  
• 符号解析：动态链接器解析a.out中调用的libc函数（如printf），将其地点填入进程的全局偏移表（GOT）
  

---

6. 虚拟地点不一致的影响

• 进程独立性：虚拟地点不同不影响进程的正确性，由于进程通过页表访问物理内存，且共享库代码为位置无关。
  
• 性能开销：若共享库未编译为PIC，动态链接器需举行重定位，增加启动时间
  

---

总结

共享库的虚拟地点分配机制通过动态链接器的地点选择、位置无关代码和页表映射实现。只管不同进程的虚拟地点可能不同，但共享库的物理内存仅保留一份副本，从而在包管进程独立性的同时节流内存资源。这一机制是操纵体系高效管理内存和多进程资源共享的焦点技能之一

---

prompt3:

我们可以知道mmap可以创建虚拟地点，那么创建的这个虚拟地点他所用的页表和物理地点是怎么来的呢

---

在Linux体系中，mmap通过虚拟地点映射将文件、装备或匿名内存区域映射到进程的虚拟地点空间。其焦点机制涉及页表管理和物理地点分配，详细实现过程如下：

---

1. 虚拟地点的创建与页表管理

• 虚拟地点分配：
  mmap通过内核的vm_area_struct布局为进程分配一段连续的虚拟地点空间（属于进程的Memory Mapping Segment区域）。该虚拟地点范围由内核动态选择，通常位于堆和栈之间
  
• 页表更新：
  内核调用remap_pfn_range函数创建页表项，将虚拟地点映射到物理地点。每个进程的页表（由MMU管理）记录虚拟地点到物理地点的映射关系。例如，ARM架构的一级页表通过虚拟地点高位（如VA[31:20]）索引页表项，获取物理地点高位（PA[31:20]），完成地点转换
  

---

2. 物理地点的来源

物理地点的分配取决于mmap的映射范例：
   （1）文件映射

  

• 磁盘文件：
  映射文件时，物理地点对应文件的磁盘块（通过文件体系inode定位）。初次访问时触发缺页非常，内核将文件内容加载到物理内存的页面缓存中，并更新页表项指向该物理页
  
• 共享物理页：
  多个进程映射同一文件时，共享同一物理页（代码段只读，数据段通过COW机制私有化）
  

   （2）匿名映射

  

• 物理内存分配：
  匿名映射（如MAP_ANONYMOUS）的物理地点由内核动态分配空闲物理页。初次访问时触发缺页，内核分配物理页并清零初始化
  

   （3）装备内存映射

  

• 硬件装备：
  映射装备寄存器或DMA缓冲区时（如/dev/mem），物理地点直接来自装备的物理地点空间，需通过remap_pfn_range将装备物理页框号（PFN）映射到用户虚拟地点
  

---

3. 缺页非常与物理内存加载

   mmap的映射过程分为两个阶段：
  

• 虚拟地点映射创建：
  内核仅创建虚拟地点区域和页表项，但此时物理内存可能未分配（文件未加载或匿名页未初始化） 
  
• 初次访问触发缺页：
  当进程访问虚拟地点时，MMU发现页表项无效，触发缺页非常。内核处理非常：
  

  

• 
  
  
  
  • 文件映射：从磁盘读取数据到物理内存，更新页表项指向该物理页
    
  • 匿名映射：分配物理页并初始化为零
    
  
  

  

---

4. 页表与物理地点的动态管理

• 页表独立性：
  每个进程拥有独立的页表，即使映射同一物理内存（如共享库），不同进程的虚拟地点可能不同，但页表项指向相同物理页
  
• 写时复制（COW）：
  对私有映射（MAP_PRIVATE）的写操纵会触发COW，内核复制物理页并更新页表项指向新页，保持原始物理页不变
  

---

5. 用户态与内核态协作

• 用户态调用：
  用户步伐通过mmap体系调用指定映射参数（地点、长度、权限等）。
  
• 内核态实现：
  内核验证参数正当性后，调用do_mmap分配虚拟地点区域，并通过文件操纵或驱动步伐的mmap方法（如remap_pfn_range）完成物理地点映射
  

---

总结

mmap通过以下机制实现虚拟地点到物理地点的映射：

• 虚拟地点分配：由内核动态选择进程的Memory Mapping Segment区域。
  
• 页表管理：通过remap_pfn_range更新页表项，创建虚拟地点与物理地点的映射。
  
• 物理地点来源：文件映射从磁盘加载，匿名映射由内核分配，装备映射直接使用硬件地点。
  
• 按需加载：缺页非常机制延迟物理内存的分配与加载，提高资源使用率
  

---

prompt4

文件描述符 fd 究竟是什么？

fd 是什么？
fd 是 File descriptor 的缩写，中文名叫做：文件描述符。文件描述符是一个非负整数，本质上是一个索引值（这句话非常告急）。
 
什么时间拿到的 fd ？
当打开一个文件时，内核向进程返回一个文件描述符（ open 体系调用得到 ），后续 read、write 这个文件时，则只需要用这个文件描述符来标识该文件，将其作为参数传入 read、write 。
fd 的值范围是什么？
在 POSIX 语义中，0，1，2 这三个 fd 值已经被赋予特别寄义，分别是标准输入（ STDIN_FILENO ），标准输出（ STDOUT_FILENO ），标准错误（ STDERR_FILENO ）。
文件描述符是有一个范围的：0 ～ OPEN_MAX-1 ，最早期的 UNIX 体系中范围很小，现在的主流体系单就这个值来说，变化范围是几乎不受限制的，只受到体系硬件配置和体系管理员配置的约束。
你可以通过 ulimit 下令查看当前体系的配置：

1. ➜  ulimit -n
2. 4864

复制代码

如上，我体系上进程默认最多打开 4864 文件。

窥探 Linux 内核

   fd 究竟是什么？必须去 Linux 内核看一眼。
  用户使用体系调用 open 或者 creat 来打开或创建一个文件，用户态得到的效果值就是 fd ，后续的 IO 操纵全都是用 fd 来标识这个文件，可想而知内核做的操纵并不简朴，我们接下来就是要揭开这层面纱。
task_struct
首先，我们知道进程的抽象是基于 struct task_struct 布局体，这是 Linux 里面最复杂的布局体之一 ，成员字段非常多，我们今天不需要详解这个布局体，我轻微简化一下，只提取我们今天需要明白的字段如下：

1. struct task_struct {
2.     // ...
3.     /* Open file information: */
4.     struct files_struct     *files;
5.     // ...
6. }

复制代码

files; 这个字段就是今天的主角之一，files 是一个指针，指向一个为 struct files_struct 的布局体。这个布局体就是用来管理该进程打开的全部文件的管理布局。
   重点明白一个概念：
  struct task_struct 是进程的抽象封装，标识一个进程，在 Linux 里面的进程各种抽象视角，都是这个布局体给到你的。当创建一个进程，其实也就是 new 一个 struct task_struct 出来；
files_struct
好，上面通过进程布局体引出了 struct files_struct 这个布局体。这个布局体管理某进程打开的全部文件的管理布局，这个布局体本身是比较简朴的：

1. /*
2. * Open file table structure
3. */
4. struct files_struct {
5.     // 读相关字段
6.     atomic_t count;
7.     bool resize_in_progress;
8.     wait_queue_head_t resize_wait;
10.     // 打开的文件管理结构
11.     struct fdtable __rcu *fdt;
12.     struct fdtable fdtab;
14.     // 写相关字段
15.     unsigned int next_fd;
16.     unsigned long close_on_exec_init[1];
17.     unsigned long open_fds_init[1];
18.     unsigned long full_fds_bits_init[1];
19.     struct file * fd_array[NR_OPEN_DEFAULT];
20. };

复制代码

files_struct 这个布局体我们说是用来管理全部打开的文件的。怎么管理？本质上就是数组管理的方式，全部打开的文件布局都在一个数组里。这可能会让你迷惑，数组在那里？有两个地方：

• struct file * fd_array[NR_OPEN_DEFAULT] 是一个静态数组，随着 files_struct 布局体分配出来的，在 64 位体系上，静态数组巨细为 64；
  
• struct fdtable 也是个数组管理布局，只不外这个是一个动态数组，数组边界是用字段描述的；
  

   思索：为什么会有这种静态 + 动态的方式？
  性能和资源的权衡 ！大部分进程只会打开少量的文件，所以静态数组就够了，这样就不消另外分配内存。如果凌驾了静态数组的阈值，那么就动态扩展。
   可以回想下，这个是不是跟 inode 的直接索引，一级索引的优化思路类似。
  fdtable

简朴先容下 fdtable 布局体，这个布局体就是封装用来管理 fd 的布局体，fd 的秘密就在这个里面。简化布局体如下：

1. struct fdtable {
2.     unsigned int max_fds;
3.     struct file __rcu **fd;      /* current fd array */
4. };

复制代码

注意到 fdtable.fd 这个字段是一个二级指针，什么意思？

• 就是指向 fdtable.fd 是一个指针字段，指向的内存地点照旧存储指针的（元素指针范例为 struct file * ）。换句话说，fdtable.fd 指向一个数组，数组元素为指针（指针范例为 struct file *）。
  
• 此中 max_fds 指明数组边界。
  

---

files_struct 小结

file_struct 本质上是用来管理全部打开的文件的，内部的焦点是由一个静态数组和动态数组管理布局实现。
还记得上面我们说文件描述符fd 本质上就是索引吗？这里就把概念接上了，fd 就是这个数组的索引，也就是数组的槽位编号而已。 通过非负数 fd 就能拿到对应的 struct file 布局体的地点。

• 所以 fd 就是地点数组的索引标识，这样好给上层应用调用地点空间
  

我们把概念串起来（注意，这里为了突出 fd 的本质,把 fdtable 管理简化掉）：

 
   

• fd 真的就是 files 这个字段指向的指针数组的索引而已（仅此而已）。通过 files_struct 可以或许找到对应文件的 struct file 布局体；
  

  file

• 现在我们知道了 fd 本质是数组索引，数组元素是 struct file 布局体的指针。那么这里就引出了一个 struct file 的布局体。这个布局体又是用来干什么的呢？
  
• 这个布局体是用来表征进程打开的文件的。简化布局如下：
  

1. struct file {
2.     // ...
3.     struct path                     f_path;
4.     struct inode                    *f_inode;
5.     const struct file_operations    *f_op;
7.     atomic_long_t                    f_count;
8.     unsigned int                     f_flags;
9.     fmode_t                          f_mode;
10.     struct mutex                     f_pos_lock;
11.     loff_t                           f_pos;
12.     struct fown_struct               f_owner;
13.     // ...
14. }

复制代码

这个布局体非常告急，它标识一个进程打开的文件，下面解释 IO 干系的几个最告急的字段：

• f_path ：标识文件名
  
• f_inode ：非常告急的一个字段，inode 这个是 vfs 的 inode 范例，是基于详细文件体系之上的抽象封装；
  
• f_pos ：这个字段非常告急，偏移，对，就是当前文件偏移。还记得上一篇 IO 根本里也提过偏移对吧，指的就是这个，f_pos 在 open 的时间会设置成默认值
  
• seek 的时间可以更改，从而影响到 write/read 的位置；
  

思索标题

   思索标题一：files_struct 布局体只会属于一个进程，那么struct file 这个布局体呢，是只会属于某一个进程？照旧可能被多个进程共享？
  划重点：struct file 是属于体系级别的布局，换句话说是可以共享与多个不同的进程。
   思索标题二：什么时间会出现多个进程的 fd 指向同一个 file 布局体？
  比如 fork 的时间，父进程打开了文件，背面 fork 出一个子进程。这种情况就会出现共享 file 的场景。如图：

 
   思索标题三：在同一个进程中，多个 fd 可能指向同一个 file 布局吗？
  可以。dup 函数就是做这个的。

1. #include <unistd.h>
2. int dup(int oldfd);
3. int dup2(int oldfd, int newfd);

复制代码

 

   inode

  我们看到 struct file 布局体里面有一个 inode 的指针，也就自然引出了 inode 的概念。

这个指向的 inode 并没有直接指向详细文件体系的 inode ，而是操纵体系抽象出来的一层虚拟文件体系，叫做 VFS （ Virtual File System ）
然后在 VFS 之下才是真正的文件体系，比如 ext4 之类的。
完整架构图如下：

   思索：为什么会有这一层vfs封装呢？
  其实很容里明白，就是解耦。

• 如果让 struct file 直接和 struct ext4_inode 这样的文件体系对接，那么会导致 struct file 的处理逻辑非常复杂，由于每对接一个详细的文件体系，就要考虑一种实现。
  
• 所以操纵体系必须把底下文件体系屏蔽掉，对外提供同一的 inode 概念，通过VFS，对下定义好接口举行回调注册。这样让 inode 的概念得以同一，Unix 一切皆文件的根本就来源于此。
  

再来看一样 VFS 的 inode 的布局：

1. struct inode {
2.     // 文件相关的基本信息（权限，模式，uid，gid等）
3.     umode_t             i_mode;
4.     unsigned short      i_opflags;
5.     kuid_t              i_uid;
6.     kgid_t              i_gid;
7.     unsigned int        i_flags;
8.     // 回调函数
9.     const struct inode_operations   *i_op;
10.     struct super_block              *i_sb;
11.     struct address_space            *i_mapping;
12.     // 文件大小，atime，ctime，mtime等
13.     loff_t              i_size;
14.     struct timespec64   i_atime;
15.     struct timespec64   i_mtime;
16.     struct timespec64   i_ctime;
17.     // 回调函数
18.     const struct file_operations    *i_fop;
19.     struct address_space            i_data;
20.     // 指向后端具体文件系统的特殊数据
21.     void    *i_private;     /* fs or device private pointer */
22. };

复制代码

• 此中包括了一些根本的文件信息，包括 uid，gid，巨细，模式，范例，时间等等。
  
• 一个 vfs 和 后端详细文件体系的纽带：i_private 字段。**用来传递一些详细文件体系使用的数据布局。
  
• 至于 i_op 回调函数在构造 inode 的时间，就注册成了后端的文件体系函数，比如 ext4 等等。
  

   思索标题：通用的 VFS 层，定义了全部文件体系通用的 inode，叫做 vfs inode，而后端文件体系也有自身特别的 inode 格式，该格式是在 vfs inode 之上举行扩展的，怎么通过 vfs inode 怎么得到详细文件体系的 inode 呢？
  下面以 ext4 文件体系举例（由于全部的文件体系套路一样），ext4 的 inode 范例是 struct ext4_inode_info 。
划重点：方法其实很简朴，这个是属于 c 语言一种常见的（也是特有）编程手法：强转范例。vfs inode 出生就和 ext4_inode_info 布局体分配在一起的，直接通过 vfs inode 布局体的地点强转范例就能得到 ext4_inode_info 布局体。

1. struct ext4_inode_info {
2.     // ext4 inode 特色字段
3.     // ...
4.    
5.     // 重要！！！
6.     struct inode    vfs_inode;  
7. };

复制代码

举个例子，现已知 inode 地点和 vfs_inode 字段的内偏移如下：

• inode 的地点为 0xa89be0；
  
• ext4_inode_info 里有个内嵌字段 vfs_inode，范例为 struct inode ，该字段在布局体内偏移为 64 字节；
  

则可以得到：
ext4_inode_info 的地点为

• (struct ext4_inode_info *)(0xa89be0 - 64)
  

强转方法使用了一个叫做 container_of 的宏，如下：

1. // 强转函数
2. static inline struct ext4_inode_info *EXT4_I(struct inode *inode)
3. {
4.    return container_of(inode, struct ext4_inode_info, vfs_inode);
5. }
7. // 强转实际封装
8. #define container_of(ptr, type, member) \
9.     (type *)((char *)(ptr) - (char *) &((type *)0)->member)
10. #endif

复制代码

  所以，你懂了吗？
  分配 inode 的时间，其实分配的是 ext4_inode_info 布局体，包含了 vfs inode，然后对外给出去 vfs_inode 字段的地点即可。VFS 层拿 inode 的地点使用，底下文件体系强转范例后，取外层的 inode 地点使用。
举个 ext4 文件体系的例子：

1. static struct inode *ext4_alloc_inode(struct super_block *sb)
2. {
3.     struct ext4_inode_info *ei;
5.     // 内存分配，分配 ext4_inode_info 的地址
6.     ei = kmem_cache_alloc(ext4_inode_cachep, GFP_NOFS);
8.     // ext4_inode_info 结构体初始化
10.     // 返回 vfs_inode 字段的地址
11.     return &ei->vfs_inode;
12. }

复制代码

vfs 拿到的就是这个 inode 地点。

三步转换过程（以ext2为例）：

• 已知指针：struct inode *vfs_inode_ptr = 0x1000 + 212（指向vfs_inode）
  
• 盘算偏移量：offsetof(struct ext2_inode_info, vfs_inode) = 212
  
• 反向盘算：(char *)vfs_inode_ptr - 212 = 0x1000（得到ext2_inode_info起始地点）
  

   抽象出了一个同一的vfs_inode_ptr, 然后通过不同的偏移量，来实现对不同文件体系接口的访问分别，例如说ext2(212B) 和ext4(64B) 他们的偏移量是不一样的
  可以明白为通过vfs_inode_ptr这一个基类，减去不同的偏移量，来实现访问不同文件体系的是一个多态的过程
  

   划重点：inode 的内存由后端文件体系分配，vfs inode 布局体内嵌在不同的文件体系的 inode 之中。不同的层次用不同的地点，ext4 文件体系用 ext4_inode_info 的布局体的地点，vfs 层用 ext4_inode_info.vfs_inode 字段的地点。
  这种用法在 C 语言编程中很常见，算是 C 的特色了（仔细想想，这种用法和面向对象的多态的实现异曲同工）。
   思索标题：怎么明白 vfsinode 和 ext2_inode_info，ext4_inode_info 等布局体的区别？
  全部文件体系共性的东西抽象到 vfs inode ，不同文件体系差异的东西放在各自的 inode 布局体中。

小结梳理

当用户打开一个文件，用户只得到了一个 fd 句柄，但内核做了很多事变，梳理下来，我们得到几个关键的数据布局，这几个数据布局是有层次递进关系的，我们简朴梳理下：
 

• 进程布局 task_struct ：表征进程实体，每一个进程都和一个 task_struct 布局体对应，此中 task_struct.files 指向一个管理打开文件的布局体 fiels_struct ；
  
• 文件表项管理布局 files_struct ：用于管理进程打开的 open 文件列表，内部以数组的方式实现（静态数组和动态数组联合）。返回给用户的 fd 就是这个数组的编号索引而已，索引元素为 file 布局；
  

• files_struct 只从属于某进程；
  
• 文件 file 布局：表征一个打开的文件，内部包含关键的字段有：当前文件偏移，inode 布局地点；
  

• 
  
  
  
  • 该布局固然由进程触发创建，但是 file 布局可以在进程间共享；
    
  
  

• vfs inode 布局体：文件 file 布局指向 的是 vfs 的 inode ，这个是操纵体系抽象出来的一层，用于屏蔽后端各种各样的文件体系的 inode 差异；
  

• 
  
  
  
  • inode 这个详细进程无关，是文件体系级别的资源；
    
  
  

• ext4 inode 布局体（指代详细文件体系 inode ）：后端文件体系的 inode 布局，不同文件体系自定义的布局体，ext2 有 ext2_inode_info，ext4 有ext4_inode_info，minix 有 minix_inode_info，这些布局里都是内嵌了一个 vfs inode 布局体，原理相同；
  

完整的架构图：

• 
  
  
   
  

思索实行

现在我们已经彻底了解 fd 这个所谓的非负整数代表的深层寄义了，我们可以准备一些 IO 的思索闻一知十。
   文件读写（ IO ）的时间会发生什么？
  

• 
  
  
  
  • 在完成 write 操纵后，在文件 file 中的当前文件偏移量会增加所写入的字节数，如果这导致当前文件偏移量超处了当前文件长度，则会把 inode 的当前长度设置为当前文件偏移量（也就是文件变长）
    
  • O_APPEND 标志打开一个文件，则相应的标识会被设置到文件 file 状态的标识中，每次对这种具有追加写标识的文件实行 write 操纵的时间，file 的当前文件偏移量首先会被设置成 inode 布局体中的文件长度，这就使得每次写入的数据都追加到文件的当前尾端处（该操纵对用户态提供原子语义）；
    
  • 若一个文件 seek 定位到文件当前的尾端，则 file 中的当前文件偏移量设置成 inode 的当前文件长度；
    
  • seek 函数值修改 file 中的当前文件偏移量，不举行任何 I/O 操纵；
    
  • 每个进程对有它自己的 file，此中包含了当前文件偏移，当多个进程写同一个文件的时间，由于一个文件 IO 终极只会是落到全局的一个 inode 上，这种并发场景则可能产生用户不可预期的效果；
    
  
  

总结

   回到初心，明白 fd 的概念有什么用？
  一切 IO 的行为到体系层面都是以 fd 的形式举行。无论是 C/C++，Go，Python，JAVA 都是一样，任何语言都是一样，这才是最本源的东西，明白了 fd 关联的一系列布局，才能对 IO 游刃有余。
简要的总结：

• 
  
  • 从姿势上来讲，用户 open 文件得到一个非负数句柄 fd，之后针对该文件的 IO 操纵都是基于这个 fd ；
    
  • 文件描述符 fd 本质上来讲就是数组索引，fd 等于 5 ，那对应数组的第 5 个元素而已，该数组是进程打开的全部文件的数组，数组元素范例为 struct file；
    
  • 布局体 task_struct 对应一个抽象的进程，files_struct 是这个进程管理该进程打开的文件数组管理器。fd 则对应了这个数组的编号，每一个打开的文件用 file 布局体表示，内含当前偏移等信息；
    
  • file 布局体可以为进程间共享，属于体系级资源，同一个文件可能对应多个 file 布局体，file 内部有个 inode 指针，指向文件体系的 inode；
    
  • inode 是文件体系级别的概念，只由文件体系管理维护，不因进程改变（ file 是进程出发创建的，进程 open 同一个文件会导致多个 file ，指向同一个 inode ）；
    
  
  

回首一眼架构图：

~完～

后记

   内核把最复杂的活干了，只暴露给我们最简朴的一个非负整数 fd 。
  所以，绝大部分场景会用fd 就行，倒不消想太多。
  当然如果能再深入看一眼知其所以然是最好不外。本文分享是根本准备篇，希望能给你带来不一样的 IO 视角。
 

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。