基础IO（3）

上篇我们接到了软硬链接的部分了，那么今天，我们继续来讲一下其他的IO补充知识。

我们知道，文件当中的数据一定会是在内存当中进行处理计算的，为什么？因为由冯诺依曼系统结构规定的。

这篇文章有讲：冯诺依曼体系结构：https://blog.csdn.net/go_bai/article/details/151992441?spm=1001.2014.3001.5501

我们又在也讲到了加载器的概念是，也提到了内存的知识了

https://blog.csdn.net/go_bai/article/details/152281549?spm=1001.2014.3001.5501

打开文件与文件系统的文件的关联

那么，这次我们继续来结合理解一下：

虚拟地址与物理页框的映射
当需要访问某个虚拟地址时，操作系统会先提取其页号（如对虚拟地址 0x11223344 ，通过与 0xFFFF F000 按位与操作，可得到页号 0x11223000 ），再通过页号找到对应的 struct page ，进而定位到实际的物理页框，完成虚拟地址到物理地址的转换。
4. 内存分配算法
- 伙伴系统算法：将内存按2的幂次大小划分成块，当需要分配内存时，找到最小的满足需求的块进行分配；释放时，尝试将相邻的同大小空闲块合并成更大的块，减少内存碎片。
​
- slab分派器：针对内核对象（如进程描述符、文件描述符等）的频繁创建和销毁，预先分配一批内存块（slab），并在其中维护对象的缓存，避免频繁的页分配与回收，提升内核内存管理效率。
 
三、IO子系统
1. IO优化的核心思路
- 硬件层面：减少IO次数，降低CPU与外设之间的通信开销。例如，通过磁盘缓存、预读等机制，让一次IO操作传输更多数据，减少访问外设的频率。
​
- 软件层面：基于局部性原理（程序在一段时间内会集中访问某块内存或文件区域），采用预加载机制，提前将可能被访问的数据加载到内存（如文件预读），避免后续的IO等待。
​
2. IO请求的管理
​
- 请求描述结构：struct request
该结构体用于描述一个IO请求，包含请求的类型（读或写）、访问的磁盘逻辑块地址（LBA）、数据缓冲区的地址、请求的大小等信息。
​
- IO请求队列（IO request queue）
操作系统维护IO请求队列，将待处理的IO请求按一定规则（如LBA顺序）组织起来。同时，支持IO排序（将随机的IO请求整理为顺序请求，提升磁盘吞吐量）和IO合并（将相邻的IO请求合并为一个大请求，减少磁头移动次数），进一步优化磁盘IO性能。
​
3. 数据交换的单位
内存与磁盘之间以页帧为单位交换数据。例如，当需要从磁盘读取文件时，操作系统会以页帧为单位将文件数据加载到内存的页框中；写入时，也以页帧为单位将内存中的数据同步到磁盘。这种以页为单位的IO操作，是内存与外设之间数据交换的基本粒度。

1. 物理内存与地址空间
物理内存是硬件层面的存储区域，有物理地址（硬件直接识别的地址）。操作系统通过内存管理单元（MMU）将物理地址映射为虚拟地址，为进程提供独立的地址空间（如上图中进程的 task_struct 、 struct inode 等数据结构，运行时处于虚拟地址空间）。
简单来说：
 - 物理地址是硬件层的“真实地址”，操作系统通过地址映射机制（如页表）管理物理地址与虚拟地址的转换，使进程能间接访问物理内存。
2. 文件系统组件与物理存储
右侧的 Super Block 、 Block Bitmap 、 inode Table 等是文件系统在磁盘（物理存储设备）上的结构，磁盘也有物理地址（扇区地址等）。操作系统通过设备驱动管理磁盘的物理地址，将磁盘上的文件系统结构映射到内存中（如将 inode 加载到物理内存的某块区域，再通过虚拟地址供进程访问）。
 例如：
- 当进程要访问一个文件时，操作系统先通过文件系统的 inode 找到磁盘上的物理块地址，再通过I/O操作将数据从磁盘的物理地址加载到物理内存，最后通过虚拟地址供进程使用。
总结
这些组件（无论是内存中的数据结构，还是磁盘上的文件系统结构）都需要通过物理地址的管理或映射，才能被操作系统有效控制和访问：
- 物理内存的组件：操作系统通过“物理地址→虚拟地址”的映射，让进程间接访问。
- 磁盘上的文件系统组件：操作系统通过设备驱动管理磁盘物理地址，实现“磁盘物理地址→内存物理地址→虚拟地址”的层级访问。
简言之，物理地址是操作系统连接硬件存储（内存、磁盘）与软件逻辑（进程、文件系统）的关键桥梁之一。

疑惑：怎么理解在Linux中，我们的每一个进程，打开的每一个文件都要有自己的inode属性和自己的文件页缓存区？？

我觉得理解这句话的核心点：进程具有独立性！

1. inode属性：文件的“身份证”与共享机制

- inode的本质：inode是文件系统中用于描述文件元数据（权限、大小、创建时间等）的结构体。（具体的看上一篇文章）多个进程可以共享同一个文件的inode（比如多个进程同时打开同一个文件时，会共享其inode信息（就比如我们上一篇的硬链接，其中使用到了引用计数），以避免元数据的重复存储。
- 进程视角的inode：每个进程在打开文件时，会通过文件描述符关联到对应的inode，但inode本身是文件的全局属性，并非进程“私有”。进程通过自身的文件描述符链（如 file_struct 、 struct file ）来访问和维护与该文件inode的关联，确保进程对文件的操作（如读写、权限检查）能基于inode的元数据进行。

2. 文件页缓冲区：进程的“私有缓存”与IO效率

- 页缓冲区的作用：Linux通过页缓存（Page Cache）来缓存文件的磁盘数据，减少磁盘IO。但每个进程对文件的页缓存访问是独立的——即使多个进程共享同一个文件，它们在内存中对该文件的页缓存映射（如通过 address_space 和 vm_area_struct 管理的虚拟内存区域）是各自维护的。
- 进程私有性的体现：比如进程A对文件某一页的修改（如写操作），会先在自己的页缓存中更新，再通过内核的同步机制刷新到磁盘；进程B若同时访问该文件，其页缓存的状态是独立的（除非是共享映射场景下的特殊处理）。这种“自己的文件页缓冲区”确保了进程对文件数据的访问隔离和效率优化。

因此！我们就可以理解上面的问题了：

- inode是文件的全局元数据，进程通过自身的文件描述符链来关联和操作它；
- 文件页缓冲区是进程在内存中对文件数据的私有缓存映射，保证了IO效率和进程间的访问隔离。
这种设计既实现了文件元数据的共享（节省资源），又保证了进程对文件数据访问的独立性（提升效率和安全性）。

好了，关于本次的分享就到处结束了，希望大家一起进步！

最后，到了本次鸡汤环节：

别着急！稳住！