从设备抽象到DMA：操作系统如何统一管理外设引言计算机可以连接大量功能完全不同的设备：
键盘产生按键事件；
串口按字节传输数据；
硬盘和SSD按照块读写；
网卡收发具有严格格式的网络帧；
GPU、摄像头和传感器又拥有各自的寄存器、协议与数据布局。
这些设备不仅用途不同，其速度、数据单位、控制方式和错误处理机制也存在巨大差异。
如果应用程序必须直接控制硬件，那么一次看似简单的“读取数据”，可能要求程序了解：
设备连接在哪条总线上；
应该访问哪个硬件寄存器；
每个寄存器中的比特代表什么；
设备何时能够接收下一条命令；
数据应该搬运到哪段内存；
操作完成后如何发现结果；
发生错误时应如何恢复。
这种设计会让每个应用程序都承担设备驱动的工作，也会使程序与特定硬件紧密绑定。
操作系统因此承担了两项核心任务：
通过抽象隐藏设备差异，为应用程序提供相对统一的访问接口。
通过设备驱动、MMIO、DMA和中断等机制，完成CPU、内存与设备之间的实际交互。
整套设备管理体系可以概括为：
123456789物理设备 ↓设备驱动 ↓字符设备、块设备、网络设备等抽象 ↓文件接口、Sock ...
从日志到闪存：日志结构文件系统与F2FS如何组织持续写入引言传统带日志文件系统通常采用如下更新流程：
12345先把修改写入日志 ↓写入Commit，确认事务完整 ↓把修改复制到文件系统正式位置
这种设计能够有效保证崩溃一致性，但也存在明显代价：同一份修改可能先写入日志，再写入正式位置，产生额外写入。
于是，日志结构文件系统提出了一个更彻底的问题：
既然日志中已经保存了最新数据，为什么还要维护另一套固定位置的文件系统结构？
日志结构文件系统，即Log-structured File System，简称LFS，选择直接把日志作为文件系统的主要存储形式。文件数据、inode和其他元数据不再频繁覆盖原位置，而是不断追加到新的位置。
其基本更新方式是：
1234567旧版本保留在原位置 ↓新版本追加到日志末尾 ↓更新映射，使新版本成为当前版本 ↓旧版本因不再被引用而失效
这种设计能够把许多离散的小写入合并成大块顺序写，尤其适合随机写代价较高的机械硬盘。
然而，异地追加也带来新的问题：
inode不断移动后，系统怎样 ...
第十三周：文件系统崩溃一致性 学习指南以下内容按照课件与学习指南规范整理：先建立主线，再解释机制、对比与易错点，最后给出不含答案的自测题。
0. 这一章到底在解决什么问题？文件系统的一次操作，往往不只是修改一个地方。
例如创建文件 /chb，至少要完成三项修改：
在 inode 分配表中，把某个 inode 标记为已占用。
初始化这个 inode。
在父目录中加入目录项，让文件名 chb 指向该 inode。
从用户角度看，这只是一次 create()；但从文件系统内部看，它是多个磁盘结构的联合修改。
问题在于：
如果系统恰好在这些修改进行到一半时断电，磁盘上会留下什么状态？
例如目录项已经写入磁盘，但 inode 还没有初始化，那么用户虽然能找到这个文件名，它却指向一个无效甚至属于其他文件的 inode。文件系统内部的数据结构关系就被破坏了。
因此，这一章研究的核心是：
如何让由多个磁盘写组成的文件系统操作，在任意时刻崩溃后，仍然保持一个可以解释、可以恢复、不会破坏内部结构的状态？
这里追求的不一定是“所有最新数据都不丢失”，而是：
文件系统结构不能损坏；
已经暴露出 ...
从文件名到虚拟文件系统：操作系统如何访问、缓存与扩展文件引言文件系统的第一层任务，是把存储设备上的数据块组织成文件和目录。但文件被组织出来以后，操作系统仍然需要回答一系列更接近实际运行的问题：
一个文件能否拥有多个名字？
进程如何引用已经打开的文件？
write()返回以后，数据是否已经写入硬盘？
文件为什么可以像内存一样被访问？
复制大型文件为什么有时能够瞬间完成？
Linux如何用同一组接口访问Ext4、FAT、NTFS和网络文件系统？
文件系统是否一定要运行在内核中？
这些问题共同构成了文件系统的运行时机制。
从应用程序的角度看，文件操作通常只是：
12345open();read();write();mmap();close();
但在这些简单接口背后，存在多个不同层次的对象：
1234567891011文件名 ↓目录项 ↓inode ↓打开文件对象 ↓文件描述符 ↓页缓存与数据块
理解这些对象之间的关系，是理解链接、文件描述符、页缓存、mmap、文件克隆、VFS和FUSE的基础。
一、文件名并不是文件本身在基于inode的文件系统中，目录中保存的核心关系通 ...
从数据块到文件：文件系统如何组织持久化存储引言从用户的视角看，存储设备中存在的是文件和目录：文件有名字、大小、类型和权限，目录可以容纳其他文件，应用程序能够按照路径打开、读取、修改或删除它们。
然而，在硬盘或SSD的底层，并不存在天然的“文件”概念。存储设备提供给操作系统的，本质上只是一大片可以按照编号访问的存储块。它不知道某些块属于一张图片，另一些块属于一段视频，更不知道/home/aster/demo.txt这样的路径意味着什么。
因此，文件系统需要完成一次关键的抽象转换：
12345底层：一系列编号的数据块 ↓ 文件系统组织与解释 ↓上层：文件、目录、路径、权限和持久化数据
文件系统的核心任务，就是记录文件由哪些数据块组成，为文件建立名称与层级关系，管理空闲空间，并在设备故障或异常断电后尽可能维持结构的一致性。
围绕“如何定位一个文件的数据”，不同文件系统发展出了不同方案。inode文件系统采用多级索引，FAT使用簇链表，NTFS则围绕MFT、区段和树形索引建立更加统一的元数据体系。它们的具体结构不同，但解决的本质 ...
Chapter 4-3：通用转发、SDN 与中间盒Chapter 4-3 的主线是网络层数据平面的进一步抽象。前面已经讨论过，传统路由器在收到 IP 数据报后，通常根据目的 IP 地址查转发表，再把分组送往某个输出端口。但现实网络中的设备远不止传统路由器：交换机、防火墙、NAT、负载均衡器、缓存、入侵检测系统等都会在数据路径上处理分组。
这些设备看起来功能不同，但从更抽象的角度看，它们都在做一件类似的事：
12345检查分组头部中的某些字段 ↓匹配某条规则 ↓执行对应动作
因此，本节的核心问题是：
1能否用一个统一模型描述各种网络设备对分组的处理逻辑？
答案就是通用转发：匹配 + 动作。SDN 和 OpenFlow 则把这种抽象进一步系统化、可编程化，使网络控制逻辑可以从传统设备中分离出来，由控制器集中计算并下发规则。
❗ 本节核心结论： Chapter 4-3 的核心不是“又学一种路由表”，而是理解网络设备处理分组的统一抽象：根据字段匹配规则，再执行转发、丢弃、修改、复制、上送控制器等动作。1. 从传统转发到通用转发传统 IP 路由器的工作方式可以简化为：
1目的 ...
Chapter 4-2：IP、编址、分片、NAT 与 IPv6 的网络层逻辑Chapter 4-2 的主线是网络层中的 IP 协议本身。上一节 Chapter 4-1 更关注数据平面的整体结构：路由器如何查表、如何通过交换结构搬运分组、如何排队和调度。本节则进入更具体的问题：IP 数据报长什么样，为什么会被分片，IP 地址到底分配给谁，子网和 CIDR 如何组织地址空间，主机如何自动获得网络配置，NAT 如何缓解 IPv4 地址不足，以及 IPv6 为什么要重新设计地址和头部格式。
这一节的核心不是背字段名，而是理解一条机制链：
12345678910111213传输层 segment ↓封装为 IP datagram ↓放入链路层 frame ↓受 MTU 限制，必要时分片 ↓根据目标 IP 和转发表逐跳转发 ↓通过子网、CIDR、路由聚合减少地址和路由管理成本 ↓借助 DHCP、NAT、IPv6 处理配置和地址规模问题
❗ 本节核心结论： IP 地址体系的核心不是“给机器编号”，而是“给接口编号，并用前缀、掩码和路由表项把接口组织成可转发、可 ...
Chapter 4-1：网络层数据平面如何完成逐跳转发Chapter 4-1 的主线是网络层的数据平面。它讨论的不是某一条具体路由协议如何计算最短路径，而是一个更底层、更频繁发生的问题：当一个 IP 数据报进入路由器后，路由器如何在本地快速决定输出端口，并把它送往下一跳。
从端到端视角看，传输层交下来的 segment 会被网络层封装成 datagram。这个 datagram 经过一个个路由器时，每个路由器都会检查其头部，根据转发表做出本地转发决策，再通过链路层重新封装后发往下一跳。
❗ 本节核心结论： 网络层数据平面的核心任务，是让每个路由器对经过自己的 IP 数据报做出高速、本地、逐跳的转发决策。1. 网络层到底解决什么问题网络层位于传输层之下、链路层之上。它解决的是主机到主机的数据报传送问题。
传输层关注的是进程到进程通信。例如浏览器进程和 Web 服务器进程之间通过 TCP 或 UDP 交换 segment。但真实网络中，segment 不会直接从一个进程“飞到”另一个进程，而是要经过主机、链路、路由器和下一跳链路。因此，网络层需要把传输层 segment 封装成 IP 数 ...
来源：根据你上传的 Chapter3-5.md 对话转录整理。
Chapter 3-5：拥塞控制原理、TCP 拥塞控制与传输层演化学习指南这一节的核心问题是：
当网络中有很多发送方同时发送数据，导致路由器队列、链路带宽等资源不够用时，TCP 应该如何调节发送速率，既避免把网络挤爆，又尽量充分利用带宽？
前面学习 TCP 可靠传输时，重点是：
数据丢了怎么办；
ACK 怎么确认；
超时怎么重传；
如何保证可靠、按序交付。
但这一节进一步追问：
如果很多 TCP 连接都在发送、都在重传、都在增加速率，网络整体会不会越来越糟？
答案是：会。
所以 TCP 不能只会“丢了就重传”，还必须会“网络拥塞时主动降速”。
0. 本节核心主线
flowchart TD
A[多个发送方共享网络] --> B[链路和路由器缓存成为瓶颈]
B --> C[排队延迟增大]
C --> D[缓存溢出导致丢包]
D --> E[发送方重传]
E --> F[网络负载进一步增加]
F --> G[需要拥塞控制]
...
Chapter 3-4：TCP 可靠传输、流量控制与连接管理学习指南这份课件主体内容是传输层中的 TCP。如果前几节 rdt、GBN、SR 讨论的是“可靠传输的原理模型”，这一节就是把这些思想落到真实 Internet 传输层协议 TCP 上。
TCP 要解决的问题是：
在 IP 本身不可靠的基础上，如何为应用进程提供一种可靠、按序、面向连接、可控速率的字节流传输服务？
0. 本节核心主线TCP 的核心能力可以压缩成一条链：
flowchart TD
A[IP 不可靠] --> B[TCP 维护连接状态]
B --> C[用字节序号标识数据位置]
C --> D[用累计 ACK 确认连续字节]
D --> E[用 RTT 估计设置超时]
E --> F[用重传和快速重传恢复丢包]
F --> G[用 rwnd 做流量控制]
G --> H[用三次握手/FIN 管理连接]
❗ 本节核心结论：TCP 不是让网络层变可靠，而是在端系统之间维护序号、ACK、窗口、定 ...
