打开文件 和 文件系统的文件产生关联

补充1：硬件级别磁盘和内存之间数据交互的基本单位
OS的内存管理
内存的本质是对数据临时存/取，把内存看成很大的缓冲区

物理内存和磁盘交互的单位是4KB，磁盘中未被打开的文件数据块也是4KB，所以磁盘中页帧也是4KB，内存中叫页框

我这个文件可能没有4KB，就一个字节，但不好意思加载4KB
我这个文件4KB，想修改1字节，也得加载4KB

为什么它不是要多少加载多少，而是一个固定大小4KB呢？
1、和磁盘交互比较慢，一共4KB每次要1KB的效率不如一气直接4KB，因为磁盘只需要定位一次
2、如果4KB文件你只要100字节，你能保证你下一次不用这文件上下文的其他数据吗？反正拿100字节还是4KB效率差不多，因为估摸着你后面的字节大概率也要用
局部性原理：正在访问代码区域附近也大概率会有数据代码被访问
这是一种预加载机制

那系统中向文件写了100字节，实际上保存100字节需要4KB？把数据交换的物理内存也要花4KB？
是的，文件大小从中做了一些事情
不用担心浪费问题，文件特别大前面那些内容把4KB都写满了，只有最后一个块被浪费了，小文件的就更不用说了

补充2：操作系统如何管理内存

操作系统必须能看到内存的物理地址
操作系统如何管理内存呢？
内存已经是一个一个4KB大小，非常多
我怎么知道哪些4KB被用到了，那些没被用
先描述，在组织！
struct page
{
//page页必要的属性信息
}
描述其中一个4KB
物理内存4G B 就有100多万的页

struct page mem_array[1048576];
对内存的管理变成了对数组的管理！！
数组天然是有下标的，所以每一个page天然有了页号的概念
如果此时任意一个地址0x11223344 & 0xFFFF F000，相当于求的是这个页的4KB对齐的起始地址
有了这个任意页的地址，应该就能通过找到对应的page数组对应的下标（我猜就是页地址也就是&完的地址减去第一个Page地址然后除以4就能得到下标）（都拿到地址了还有啥找不到的），进行物理内存管理
结论：
所有申请内存的动作，都是在访问内存page数组，都是对这个数组增删查改

struct page mem_array[1048576] 一定像链表一样有对应的数据结构方法，调算法申请内存

补充3：