原文链接
操作系统导论
推荐阅读
https://weread.qq.com/web/reader/db8329d071cc7f70db8a479kc81322c012c81e728d9d180
阅读感想
操作系统最伟大的地方就是他的抽象，将CPU虚拟化，把一个物理CPU变成了多个虚拟CPU，从而支持多个程序并发运行；通过内存虚拟化，将物理内存抽象为多个巨大的、高速的虚拟内存，让每一个进程都以为自己拥有无限大内存空间。
第4章 进程
运行的程序就是进程，操作系统有很多关于进程的API，
·创建（create）：操作系统必须包含一些创建新进程的方法。在shell中键入命令或双击应用程序图标时，会调用操作系统来创建新进程，运行指定的程序。
·销毁（destroy）：由于存在创建进程的接口，因此系统还提供了一个强制销毁进程的接口。当然，很多进程会在运行完成后自行退出。但是，如果它们不退出，用户可能希望终止它们，因此停止失控进程的接口非常有用。
·等待（wait）：有时等待进程停止运行是有用的，因此经常提供某种等待接口。
·其他控制（miscellaneous control）：除了杀死或等待进程外，有时还可能有其他控制。例如，大多数操作系统提供某种方法来暂停进程（停止运行一段时间），然后恢复（继续运行）。
·状态（status）：通常也有一些接口可以获得有关进程的状态信息，例如运行了多长时间，或者处于什么状态。
把程序和静态数据加载到内存，然后执行他就成了进程，现代操作系统将加载的过程lazily懒惰化了，需要用的时候才加载
进程有三个状态，运行、就绪、阻塞
第5章 进程API
fork , 复制当前的进程，父进程返回子进程pid，子进程返回0
wait，父进程等待子进程执行完毕
exec，加载某个程序到内存中运行，覆盖当前进程
shell也是一个用户程序[插图]，它首先显示一个提示符（prompt），然后等待用户输入。你可以向它输入一个命令（一个可执行程序的名称及需要的参数），大多数情况下，shell可以在文件系统中找到这个可执行程序，调用fork()创建新进程，并调用exec()的某个变体来执行这个可执行程序，调用wait()等待该命令完成。子进程执行结束后，shell从wait()返回并再次输出一个提示符，等待用户输入下一条命令。
第6章 机制：受限直接执行
OS不可能说，创建了一个进程，把所有权限完全交给进程，然后把自己挂起，那坏蛋写一个死循环，我们就只能重启计算机了，OS会把CPU交给进程，但是他如何拿回来呢？
答案很简单，许多年前构建计算机系统的许多人都发现了：时钟中断（timer interrupt）[M+63]。时钟设备可以编程为每隔几毫秒产生一次中断。产生中断时，当前正在运行的进程停止，操作系统中预先配置的中断处理程序（interrupt handler）会运行。此时，操作系统重新获得CPU的控制权，因此可以做它想做的事：停止当前进程，并启动另一个进程。
第8章 调度：多级反馈队列
·规则1：如果A的优先级 > B的优先级，运行A（不运行B）。
·规则2：如果A的优先级 = B的优先级，轮转运行A和B。
·规则3：工作进入系统时，放在最高优先级（最上层队列）。
·规则4：一旦工作用完了其在某一层中的时间配额（无论中间主动放弃了多少次CPU），就降低其优先级（移入低一级队列）。
·规则5：经过一段时间S，就将系统中所有工作重新加入最高优先级队列。
规则4是反馈
规则5可避免饥饿
第9章 调度： 比例份额
彩票调度
很多人都买过彩票，但是很少有人中奖，我们假设有100张彩票，有AB两个人分别买了75张和25张，然后我们进行随机开奖，开到一张票，这张票在谁手上谁就中奖。
同理，我们假设AB是两个进程，则中奖的那位就能获得CPU控制权。
彩票货币
如果进程可以将自己的彩票分配给自己的线程，则实现了彩票货币化。
彩票转让
一个进程可以吧自己的彩票分给其他进程，例如客户端把彩票分给服务端以加快服务端处理速度。
彩票通胀
最后，彩票通胀（ticket inflation）有时也很有用。利用通胀，一个进程可以临时提升或降低自己拥有的彩票数量。当然在竞争环境中，进程之间互相不信任，这种机制就没什么意义。
算法实现
我们只需要记录每个进程拥有多少彩票，并把他们排好，然后OS生产随机数，从第一个进程开始，对彩票数进行累加，当累和第一次超过随机数时，这个进程中奖。
我们还可以对进程按照彩票数从大到小排好序，这样可以加快遍历速度。
步长调度
A、B、C这3个工作的票数分别是100、50和250，我们通过用一个大数分别除以他们的票数来获得每个进程的步长。比如用10000除以这些票数值，得到了3个进程的步长分别为100、200和40。我们称这个值为每个进程的步长（stride）。每次进程运行后，我们会让它的计数器 [称为行程（pass）值] 增加它的步长，记录它的总体进展。
当进行调度的时候，取出行程最小的进程进行调度，如果有多个，则从中随机选择任意一个。
第10章 多处理器调度（高级）
问题
- 缓存一致性： CPU1修改了自己的缓存，但是CPU2没有同步修改怎么办？
硬件提供了这个问题的基本解决方案：通过监控内存访问，硬件可以保证获得正确的数据，并保证共享内存的唯一性。在基于总线的系统中，一种方式是使用总线窥探（bus snooping）[G83]。每个缓存都通过监听链接所有缓存和内存的总线，来发现内存访问。如果CPU发现对它放在缓存中的数据的更新，会作废（invalidate）本地副本（从缓存中移除），或更新（update）它（修改为新值）。回写缓存，如上面提到的，让事情更复杂（由于对内存的写入稍后才会看到），你可以想想基本方案如何工作
- 并行(发)问题：
如果线程1执行第一行，会将head的当前值存入它的tmp变量。如果线程2接着也执行第一行，它也会将同样的head值存入它自己的私有tmp变量（tmp在栈上分配，因此每个线程都有自己的私有存储）。因此，两个线程会尝试删除同一个链表头，而不是每个线程移除一个元素，
void rease(){
Node *tmp = head;
// ...
free(tmp);
}
- 缓存亲和度： 一个线程在某个CPU上运行，他会有一些缓存，如果他切换到其他CPU上，则缓存需要重新加载。
单队列多处理器调度
（Single QueueMultiprocessor Scheduling，SQMS) 一个队列，处理器需要执行时，锁住队列，然后从队列取出任务，最后释放锁，但是他不好解决亲和度问题和锁的问题。
多队列多处理器调度
（Multi-QueueMultiprocessor Scheduling，MQMS）多个队列，一般而言，一个处理器一个队列，如果任务数量能整除CPU数量，这很好分配，无法整除的时候，就涉及到了负载不均的问题。
最明显的答案是让工作移动，这种技术我们称为迁移（migration）。通过工作的跨CPU迁移，可以真正实现负载均衡。
注意我们要让任务轮流迁移，否则就不太公平
另一个方法是窃取工作量少的队列不定期偷看其他队列，如果发现他比自己多，则偷取一个任务。
如果太频繁地检查其他队列，就会带来较高的开销，可扩展性不好，而这是多队列调度最初的全部目标！相反，如果检查间隔太长，又可能会带来严重的负载不均。
第15章 机制：地址转换
动态（基于硬件）重定位
即基址加界限机制，所有的程序都认为自己的地址空间从0开始，但是当他执行的时候，操作系统会决定其在物理内存中的实际加载地址，并将起始地址记录在基址寄存器中。
第16章 分段
问题：栈和堆之间，有一大块“空闲”空间，造成了浪费
在硬件中使用三对寄存器来分别记录代码段，堆和栈
问题： 如何判断一个地址是代码段，堆还是栈？
虚拟地址前两位表示
问题： 如何共享？
操作系统为段记录额外信息，
第17章 空闲空间管理
要满足变长的分配请求，应该如何管理空闲空间？什么策略可以让碎片最小化？不同方法的时间和空间开销如何？
OS如何知道free的内存有多大？
在C中，每当我们使用malloc的时候，OS会给我们分配一块内存，当我们使用free的时候，这块内存会被释放，然而这个时候OS如何知道这块内存有多大，他该如何来释放呢？
其实malloc返回给我们的内存是小于OS给我们的内存的，可以看到OS在这块内存的前面加了一些信息，包括内存的大小和一个校验部分。
OS如何组织空闲内存？
每块内存的开头都有一个部分，包括这块内存的大小以及下一块内存的地址
内存分配和释放
OS分配内存的时候，会在他的内存链表中找到一块合适的，将其切割并移除链表分配给应用程序，当OS回收的时候，会将其放回链表，但是这个办法经历了长时间的内存管理以后，OS的内存将会一团糟，这个时候操作系统又会合并相邻块，之后内存又成为了一个整体。
如何选择链表中的内存块？
| 匹配算法 | 备注 | | | - | - | - | | 最优匹配 | 在所有可以分割的节点中，选择内存最小的那个节点 | | | 最差匹配 | 在所有可以分割的节点中，选择内存最大的那个节点 | | | 首次匹配 | 寻找过程中，发现的第一个能匹配的节点 | | | 下次匹配 | 在首次匹配的基础上，每次查询的链表起点就是上一次匹配的节点 | |
有趣的匹配算法
分离空闲列表：
如果某个应用程序经常申请一种（或几种）大小的内存空间，那就用一个独立的列表，只管理这样大小的对象。其他大小的请求都交给更通用的内存分配程序。
伙伴系统:
第18章 分页：介绍
页表是什么，在哪里？
用一张表，储存虚拟地址到物理地址的映射，往往虚拟地址和物理地址的前几位是不同的，这些不同的位被称为页，而剩下的成为偏移量。从虚拟地址映射到物理地址只需要将前几位进行转换即可，这张表就叫做页表。
页表储存在内存中，每个进程都拥有一份自己的页表。
页表中有什么
页表往往是一个数组映射，所以没有物理叶帧（数组下标）
| 代号 | 意义 | 备注 | | :-: | :-: | :-: | | P | 存在位 | 表示该页表是否被进程申请使用 | | R/W | 读写权限位 | 表示该页面权限是可读还是可写 | | U/S | 访问是否需要特权级 | | | PWT | | | | PCD | | | | A | 访问位 | 近期是否访问过该页 | | D | 脏位 | 该页是否被写 | | PAT | | | | G | | | | ？ | 操作系统自定义使用 | | | PFN | 叶帧 | |
分页很慢
分页机制导致与内存发生的交互次数翻倍了，程序更慢了。
第19章 分页：快速地址转换（TLB）
高速页表缓冲区：地址转换旁路缓冲存储器（translation-lookasidebuffer）
这是一个硬件，他能缓存页表地址转化，速度远高于内存读取
TLB未命中
TLB和其他缓存相似，前提是在一般情况下，转换映射会在缓存中（即命中）。如果是这样，只增加了很少的开销，因为TLB处理器核心附近，设计的访问速度很快。如果TLB未命中，就会带来很大的分页开销。必须访问页表来查找转换映射，导致一次额外的内存引用（或者更多，如果页表更复杂）。如果这经常发生，程序的运行就会显著变慢。相对于大多数CPU指令，内存访问开销很大，TLB未命中导致更多内存访问。因此，我们希望尽可能避免TLB未命中。
一般是操作系统来处理未命中，发生未命中，硬件抛异常，进入内核，陷入操作系统，操作系统更新TLB，返回之前的未命中代码进行重试
重点细节：
- 返回进入陷阱的那条代码重试。
- OS千万不能在处理TLB时又触发未命中，这将导致无限递归。
进程上下文切换
页表是进程私有的，如果发生了进程上下文切换，则TLB全部变为无效。
上下文切换的时候清空TLB，这是一个可行的解决方案，进程不会再读到错误的地址映射。但是，有一定开销：每次进程运行，当它访问数据和代码页时，都会触发TLB未命中。如果操作系统频繁地切换进程，这种开销会很高。
为了减少这种开销，一些系统增加了硬件支持，实现跨上下文切换的TLB共享。比如有的系统在TLB中添加了一个地址空间标识符（Address Space Identifier，ASID）。可以把ASID看作是进程标识符（Process Identifier，PID），但通常比PID位数少（PID一般32位，ASID一般是8位）。
TLB项中有什么
TLB是并行硬件，他可以并行查找
| 代号 | 意义 | 备注 | | :-: | :-: | :-: | | VPN | | | | R/W | 全局位 | 是否全局共享 | | | | | | PWT | 进程空间 | 属于哪个进程 | | | | | | PFN | | | | C | 一致位 | 决定硬件如何缓存 | | D | 脏位 | 是否被写入新数据 | | V | 有效位 | 该映射是否有效（注意区别页表的存在位） | | | | |
第20章 分页：较小的表
页表太大，因此消耗的内存太多。
假设一个32位地址空间（232字节），4KB（212字节）的页和一个4字节的页表项。一个地址空间中大约有一百万个虚拟页面（232/212）。乘以页表项的大小，你会发现页表大小为4MB。
使用更大的页
这种方法的主要问题在于，大内存页会导致每页内的浪费，这被称为内部碎片（internalfragmentation）问题
结合分段
我们可能有3个页表，地址空间的代码、堆和栈部分各有一个
杂合方案的关键区别在于，每个分段都有界限寄存器，每个界限寄存器保存了段中最大有效页的值。
分段并不像我们需要的那样灵活，因为它假定地址空间有一定的使用模式。例如，如果有一个大而稀疏的堆，仍然可能导致大量的页表浪费。
多级页表
分配更多级的页表，这是使用时间换空间
反向页表
记录物理页映射到虚拟页，而不是虚拟页映射到物理页
第21章 超越物理内存：机制
我们的内存始终是有限的，如何超越这个限制，为应用程序提供无限空间的假象呢？
操作系统如何利用大而慢的设备，透明地提供巨大虚拟地址空间的假象？
操作系统利用大而慢的磁盘和内存中的数据进行交换，借此实现了超越物理内存的目的。
页错误
如果一个页不存在，它已被交换到硬盘，在处理页错误的时候，操作系统需要将该页交换到内存中。那么，问题来了：操作系统如何知道所需的页在哪儿？在许多系统中，页表是存储这些信息最自然的地方。因此，操作系统可以用PTE中的某些位来存储硬盘地址，这些位通常用来存储像页的PFN这样的数据。当操作系统接收到页错误时，它会在PTE中查找地址，并将请求发送到硬盘，将页读取到内存中。
交换何时发生？
OS不会等到内存完全满了才进行交换，OS往往会预留BUF。
为了保证有少量的空闲内存，大多数操作系统会设置高水位线（High Watermark，HW）和低水位线（Low Watermark，LW），来帮助决定何时从内存中清除页。原理是这样：当操作系统发现有少于LW个页可用时，后台负责释放内存的线程会开始运行，直到有HW个可用的物理页。这个后台线程有时称为交换守护进程（swap daemon）或页守护进程（page daemon）[插图]，它然后会很开心地进入休眠状态，因为它毕竟为操作系统释放了一些内存
第22章 超越物理内存：策略
最优替换策略
只存在于理论上的策略，他的作用是评估其他算法
FIFO
先进先出
补充：Belady的异常Belady（最优策略发明者）及其同事发现了一个有意思的引用序列[BNS69]。内存引用顺序是：1，2，3，4，1，2，5，1，2，3，4，5。他们正在研究的替换策略是FIFO。有趣的问题：当缓存大小从3变成4时，缓存命中率如何变化？
一般来说，当缓存变大时，缓存命中率是会提高的（变好）。但在这个例子，采用FIFO，命中率反而下降了！你可以自己计算一下缓存命中和未命中次数。这种奇怪的现象被称为Belady的异常（Belady’s Anomaly）。
其他一些策略，比如LRU，不会遇到这个问题。可以猜猜为什么？事实证明，LRU具有所谓的栈特性（stack property）[M+70]。对于具有这个性质的算法，大小为N + 1的缓存自然包括大小为N的缓存的内容。因此，当增加缓存大小时，缓存命中率至少保证不变，有可能提高。先进先出（FIFO）和随机（Random）等显然没有栈特性，因此容易出现异常行为。
随机
随机选择一个换出去
LRU
最近最少使用的页面，在最近的一段时间访问的页面中，过了很久都没有访问的那个页面，踢出去，这个算法速度较慢
近似LRU（时钟算法）
每当页被引用（即读或写）时，硬件将使用位设置为1。但是，硬件不会清除该位（即将其设置为0），这由操作系统负责
时钟指针（clock hand）开始时指向某个特定的页（哪个页不重要）。当必须进行页替换时，操作系统检查当前指向的页P的使用位是1还是0。如果是1，则意味着页面P最近被使用，因此不适合被替换。然后，P的使用位设置为0，时钟指针递增到下一页（P + 1）。该算法一直持续到找到一个使用位为0的页，使用位为0意味着这个页最近没有被使用过
脏页问题
如果一个页被修改，他会变成脏页，踢出去必须写回磁盘，这非常昂贵
为了支持这种行为，硬件应该包括一个修改位（modified bit，又名脏位，dirty bit）。每次写入页时都会设置此位，因此可以将其合并到页面替换算法中。例如，时钟算法可以被改变，以扫描既未使用又干净的页先踢出。
抖动
当内存超额的时候，系统疯狂的进行换页，这被称为抖动。现代操作系统一旦检测到抖动，就会将某些内存密集型进程杀死。
第28章 锁
笔者： 从这一章开始，到并发结束，都很难
我们希望原子式执行一系列指令，但由于单处理器上的中断（或者多个线程在多处理器上并发执行），我们做不到
如何评价一个锁？
首先是锁能否完成它的基本任务，即互斥；第二是公平性；最后是性能
控制中断
早期的解决方案是在临界区关闭中断。他有很多缺点
这种方法要求我们允许所有调用线程执行特权操作，这会导致很多麻烦，贪婪的线程独占CPU，恶意的程序死循环，系统就崩溃了
无法支持多CPU
丢失中断
效率低下
Peterson算法
一段时间以来，出于某种原因，大家都热衷于研究不依赖硬件支持的锁机制。后来这些工作都没有太多意义，因为只需要很少的硬件支持，实现锁就会容易很多（实际在多处理器的早期，就有这些硬件支持）。而且上面提到的方法无法运行在现代硬件（应为松散内存一致性模型），导致它们更加没有用处。更多的相关研究也湮没在历史中……
Test And Set
这是一个操作系统原子指令，把一个内存变量赋予新的值，并返回旧的值。
然后我们就可以实现锁了
// 操作系统原语伪代码
int testAndSet(int*ptr, int value) {
int old = *ptr;
*ptr = value;
return old;
}
// 锁
struct TasLock {
int flag;
TasLock() {
flag = 0;
}
void lock() {
while (testAndSet(&flag, 1) == 1){
// do nothing;
}
}
void unlock() {
flag = 0;
}
};
这个锁是正确的，但是他没办法保证公平，会出现饿死，在单CPU上他的性能很差，如果一个线程获取锁失败，他会一直自旋，直到时间片用完，在多CPU（线程数=CPU数）上表现不错
Compare And Swap
比较并交换，如果和旧值相等，就赋值，否则什么也不做
这个算法和上面的test and set区别其实不大
// 操作系统原语伪代码
int cas(int*ptr, int expected, int value) {
int old = *ptr;
if(old == expected) {
*ptr = value;
}
return old;
}
// 锁
struct CasLock {
int flag;
CasLock() {
flag = 0;
}
void lock() {
while (cas(&flag, 0, 1) == 1){
// do nothing;
}
}
void unlock() {
flag = 0;
}
};
链接的加载和条件式存储指令
这个算法和test and set也是一样
// 操作系统原语伪代码
int loadLinked(int *ptr) {
return *ptr;
}
int storeConditional(int *ptr, int value) {
if(自从ptr被loadLinked以来，他没有更新过) {
*ptr = value;
return 1; // success
} else {
return 0; // failed
}
}
// 锁
struct LoadLinkeLock {
int flag;
LoadLinkeLock() {
flag = 0;
}
void lock() {
while (true){
while (loadLinked(&flag) == 1) {
// do noting
}
if(storeConditional(&flag, 1) == 1) {
break;
}
}
}
void unlock() {
flag = 0;
}
};
Fetch And Add
返回旧值并让这个值加一
// 操作系统原语伪代码
int fetchAndAdd(int *ptr) {
int old = *ptr;
*ptr = old + 1;
return old;
}
// 锁
struct FAALock {
int turn;
int ticket;
FAALock() {
turn = 1;
ticket = 0;
}
void lock() {
int myTurn = fetchAndAdd(ticket);
while(turn != myTurn) {
// do noting
}
}
void unlock() {
fetchAndAdd(turn);
}
};
这个方法其实比较厉害，他能保证公平
自旋太费CPU了
让我稍微改进一下testAndSet的lock函数，新的方法避免了自旋，但是他依然会出现饥饿，例如一个线程每次都yield，另一个线程一直进出临界区
// 继承TasLock
struct YieldTasLock : TasLock {
YieldTasLock() {
supper();
}
// Override
void lock() {
while (testAndSet(&flag, 1) == 1){
yield(); // 主动放弃CPU，切换到其他线程
}
}
}
休眠队列
我们可以改进TasLock锁， 改进之后的锁产生饥饿的概率变小了，唯一的自旋出现在内置tasLock中，但是这个锁等待的时间是有限的
struct SleepQueueLock {
int flag;
TasLock *tasLock;
Queue *queue;
SleepQueueLock() {
flag = 0;
tasLock = new TasLock();
queue = new Queue();
}
void lock() {
tasLock.lock(); // 自旋获取锁
// 进入临界区
if(flag == 0) {
flag = 1;
tasLock.unlock(); // 离开临界区解锁
} else {
queue.add(getThreadId()); // 把线程加入队列
tasLock.unlock(); // 离开临界区解锁， 先解锁后park，否则死锁
// 如果注释所在的这一行发生了上下文切换，那么这个线程就可能会永远沉睡了
park(); // 线程休眠 ，
}
}
void unlock() {
tasLock.lock(); // 自旋获取锁
// 进入临界区
if(queue.isEmpty()) {
flag = 0
} else {
// 这里不用设置flag=0
unpark(queue.remove()); //唤醒一个在队列中的x
}
tasLock.unlock(); // 离开临界区解锁
}
}
最后，你可能注意到解决方案中的竞争条件，就在park()调用之前。如果不凑巧，一个线程将要park，假定它应该睡到锁可用时。这时切换到另一个线程（比如持有锁的线程），这可能会导致麻烦。比如，如果该线程随后释放了锁。接下来第一个线程的park会永远睡下去（可能）。这种问题有时称为唤醒/等待竞争（wakeup/waiting race）。为了避免这种情况，我们需要额外的工作。Solaris通过增加了第三个系统调用separk()来解决这一问题。通过setpark()，一个线程表明自己马上要park。如果刚好另一个线程被调度，并且调用了unpark，那么后续的park调用就会直接返回，而不是一直睡眠。
两阶段锁
先自旋一段时间，如果还是没有获得锁，就直接睡眠。
第29章 基于锁的并发数据结构
并发计数器
struct Counter {
int value;
Lock lock;
Counter() {
value = 0;
lock = new Lock();
}
void increment() {
lock.lock();
value ++;
lock.unlock();
}
void get() {
lock.lock();
int res = value;
lock.unlock();
return res;
}
}
这个并发计数器遵循了最简单的结构，即直接加锁。他唯一不好的地方就是他的性能太差，并发度很低。
惰性并发计数器
struct LazyCounter {
int* threadValue;
int lazyBounder;
int value;
Lock lock;
LazyCounter(int threadNumber,int lazyBounder) {
threadValue = new int[threadNumber];
for (int i = 0; i < threadNumber; i++) {
threadValue[i] = 0;
}
this->lazyBounder = lazyBounder;
value = 0;
lock = new Lock();
}
void increment(int threadId) {
threadValue[threadId] ++;
if(threadValue[threadId] = lazyBounder) {
lock.lock();
value += lazyBounder;
lock.unlock();
threadValue[threadId] = 0;
}
}
void get() {
lock.lock();
int res = value;
lock.unlock();
return res;
}
}
惰性并发计数器为每一个线程分配了一个自己的惰性累和，只有当这个累和打到了阈值以后，才会加入到全局的累和中。这个数据结构提高了并发度。
并发链表
struct List {
struct ListNode {
int value;
Listnode* next;
// ... 全参构造函数
};
ListNode* head;
Lock* lock;
// ... 全参构造函数
void insert(int value) {
lock.lock();
ListNode* listNode = new ListNode(value, null);
if (listNode == null) {
perror("没有足够的空间");
lock.unlock();
return -1; // failed
}
listNode->next = head;
head = listNode;
lock.unlock();
}
}
从代码中可以看出，代码插入函数入口处获取锁，结束时释放锁。如果new失败（在极少的时候），会有一点小问题，在这种情况下，代码在插入失败之前，必须释放锁。
事实表明，这种异常控制流容易产生错误。最近一个Linux内核补丁的研究表明，有40%都是这种很少发生的代码路径（实际上，这个发现启发了我们自己的一些研究，我们从Linux文件系统中移除了所有内存失败的路径，得到了更健壮的系统[S+11]）。
另一方面，锁的粒度还可以更小
void insert(int value) {
ListNode* listNode = new ListNode(value, null);
if (listNode == null) {
perror("没有足够的空间");
lock.unlock();
return -1; // failed
}
lock.lock();
listNode->next = head;
head = listNode;
lock.unlock();
}
过手锁
原理也很简单。每个节点都有一个锁，替代之前整个链表一个锁。遍历链表的时候，首先抢占下一个节点的锁，然后释放当前节点的锁。
从概念上说，过手锁链表有点道理，它增加了链表操作的并发程度。但是实际上，在遍历的时候，每个节点获取锁、释放锁的开销巨大，很难比单锁的方法快。即使有大量的线程和很大的链表，这种并发的方案也不一定会比单锁的方案快。也许某种杂合的方案（一定数量的节点用一个锁）值得去研究。
如果方案带来了大量的开销（例如，频繁地获取锁、释放锁），那么高并发就没有什么意义。如果简单的方案很少用到高开销的调用，通常会很有效。增加更多的锁和复杂性可能会适得其反。
并发队列
第一个方法依然是加一个大锁，这很简单。现在我们考虑其他做法。
另一个方法是对队首和队尾分别加锁。
struct Queue {
struct QueueNode {
int value;
QueueNode* next;
// ... 构造函数
};
QueueNode head;
QueueNode tail;
Lock headLock;
Lock tailLock;
// ... 构造函数
void enQueue(int value) {
QueueNode* tmp = new QueueNode(value, null);
assert(tmp != NULL);
tailLock.lock();
tail->next = tmp;
tail = tmp;
tailLock.unlock();
}
bool deQueue(int* target) {
headLock.lock();
QueueNode* tmp = head;
QueueNode* newHead = head->next;
if(newHead == NULL) {
headLock.unlock();
return false;
}
*target = newHead->value; // 取出队首
head = newHead; // 更新指向队首的节点
headLock.unlock();
delete tmp;
return true;
}
}
并发散列表
我们可以直接利用前面的并发链表来实现并发散列表，不需要增加额外的锁。
第30章 条件变量
wait与signal
前面我们了解了锁，但是锁并非并发程序设计所需的唯一原语。
具体来说，在很多情况下，线程需要检查某一条件（condition）满足之后，才会继续运行。例如，父线程需要检查子线程是否执行完毕 [这常被称为join()]。
下面展示一个使用wait()和signal()实现的父线程等待子线程的情况,
当线程睡眠可以调用wait，线程被唤醒时会自动获取锁
当另一个线程想要唤醒在这个条件变量上等待的线程时，可以调用signal，当然唤醒后不一定马上切换过去运行
struct Condition {
void wait(Lock lock); //释放锁并睡眠,醒来时获取锁
void signal(); // 唤醒在此条件上等待的线程
}
bool done = false;
Mutex *mutex = new Mutex();
Condition *condition = new Condition();
void threadExit() {
mutex.lock();
done = true;
condition->signal();
mutex.unlock();
}
void child(void *arg) {
printf("child\n");
threadExit();
}
void threadJoin() {
mutex.lock();
while(!done) {
condition->wait(mutex);
}
mutex.unlock();
}
int main() {
print("parent: begin\n");
pthread_t p;
Pthread_create(&p, NULL, child, NULL);
threadJoin();
printf("parent: end\n");
}
生产者消费者
我们假设只有一个生产者，一个消费者，
Condition *condition;
Mutex *mutex;
Queue *queue; //无并发控制的Queue
void producer(int loops) {
for(int i = 0; i < loops; i++) {
mutex->lock();
if(queue->fill()) {
condition->wait(mutex); // 队列满了，无法生产，进入睡眠
}
queue->insert(i); // 放入了一个东西
condition->signal(); // 唤醒等待条件的线程
mutex->unlock();
}
}
void consumer(int loops) {
for(int i = 0; i < loops; i++) {
mutex->lock();
if(queue->empty()) {
condition->wait(mutex); // 队列空了， 无法消费，进入睡眠
}
queue->remove(); // 从队列中取出元素，消费
condition->signal(); // 唤醒等待条件的线程
mutex->unlock();
}
}
如果只有一个消费者和一个生产者，这个代码正常工作，但是如果违反了这两个条件，这段代码会出现两个问题。
暂停思考
暂停思考
暂停思考
暂停思考
- 8行和20行不能使用if，应该是while，例如一个消费者首先wait，然后一个生产者生产并signal，接着又一个消费者抢先获取锁，并进行了消费，最后CPU调度到第一个消费者时，他已经执行过if，直接强行消费，主要原因因为被唤醒后不一定直接执行，CPU可能调度其他线程，
- 生产者应该唤醒消费者，消费者应该唤醒生产者
Condition *empty;
Condition *fill;
Mutex *mutex;
Queue *queue; //无并发控制的Queue
void producer(int loops) {
for(int i = 0; i < loops; i++) {
mutex->lock();
while (queue->fill()) {
fill->wait(mutex); // 队列满了，无法生产，进入睡眠,
}
queue->insert(i); // 放入了一个东西
empty->signal(); // 唤醒等待条件的线程
mutex->unlock();
}
}
void consumer(int loops) {
for(int i = 0; i < loops; i++) {
mutex->lock();
while (queue->empty()) {
empty->wait(mutex); // 队列空了， 无法消费，进入睡眠
}
queue->remove(); // 从队列中取出元素，消费
fill->signal(); // 唤醒等待条件的线程
mutex->unlock();
}
}
覆盖条件
即唤醒所有的线程，而不是signal中的唤醒一个。
第31章 信号量
Dijkstra及其同事发明了信号量，作为与同步有关的所有工作的唯一原语。你会看到，可以使用信号量作为锁和条件变量
接下来是信号量的定义
struct Semaphore {
int value;
// ... 全参构造函数
int wait() {
// Dijkstra 称之为 P()， 荷兰语： to probe
// 人们有时候会用 down()
// 要么直接返回，要么挂起并等待post
// value --, 如果value为负数，则挂起等待
}
int post() {
// Dijkstra 称之为 V()， 荷兰语： to test
// 人们有时候会用 up()
// 增加信号量，如果有等待的线程，则唤醒
// value ++， 如果有一个或多个线程等待，则唤醒一个
}
}
二值信号量（锁）
如果初始信号量为1， 则信号量就是锁
信号量作为条件变量
如果初始信号量为0，则信号量就是条件变量
生产者与消费者
先来一个很简单的有bug的代码，来找找bug（一个）
Semaphore *fill = new Semaphore(0); //
Semaphore *empty = new Semaphore(MAX); // 初始队列没有任何东西，视为全部是空
void producer(int loops) {
for(int i = 0; i < loops; i++) {
empty->wait(); // 等待空的条件
queue->insert(i); // 放入了一个东西
fill->post(); // 通知消费者，满
}
}
void consumer(int loops) {
for(int i = 0; i < loops; i++) {
fill->wait(); // 等待满的条件
queue->remove(); // 从队列中取出元素，消费
empty->post(); // 通知生产者，空
}
}
bug很明显，没有锁。如果有多个生产者，他们会同时执行第7行，这将导致很明显的并发问题，我们通过下面的代码直接加锁,但是这和条件变量相比，还是有一点问题，他会死锁，由于条件变量的wait会释放锁，但是信号量却不会。
Semaphore *fill = new Semaphore(0); //
Semaphore *empty = new Semaphore(MAX); // 初始队列没有任何东西，视为全部是空
+ Semaphore *mutex = new Semaphore(1); // 锁
void producer(int loops) {
for(int i = 0; i < loops; i++) {
+ mutex->wait();
empty->wait(); // 等待空的条件
queue->insert(i); // 放入了一个东西
fill->post(); // 通知消费者，满
+ mutex->post();
}
}
void consumer(int loops) {
for(int i = 0; i < loops; i++) {
+ mutex->wait();
fill->wait(); // 等待满的条件
queue->remove(); // 从队列中取出元素，消费
empty->post(); // 通知生产者，空
+ mutex->post();
}
}
最后我们交换锁的位置，这个程序就并发安全了。但是为什么？又该如何证明一个程序时并发安全的？
Semaphore *fill = new Semaphore(0); //
Semaphore *empty = new Semaphore(MAX); // 初始队列没有任何东西，视为全部是空
Semaphore *mutex = new Semaphore(1); // 锁
void producer(int loops) {
for(int i = 0; i < loops; i++) {
empty->wait(); // 等待空的条件
mutex->wait();
queue->insert(i); // 放入了一个东西
mutex->post();
fill->post(); // 通知消费者，满
}
}
void consumer(int loops) {
for(int i = 0; i < loops; i++) {
fill->wait(); // 等待满的条件
mutex->wait();
queue->remove(); // 从队列中取出元素，消费
mutex->post();
empty->post(); // 通知生产者，空
}
}
读写锁，哲学家进餐，吸烟者问题，理发师问题？
再见。代码谁都可以看懂，但是你知道如何证明他是对的吗？
实现信号量
让我们用锁和条件变量来实现信号量
struct Semaphore {
int value;
Condition *condition;
Lock *lock;
Semaphore(int value) {
this->value = value;
this->condition = new Condition();
this->lock = new Lock();
}
void wait() {
lock->lock();
value --;
while(value < 0) {
condition->wait(lock);
}
lock->unlock();
}
void post() {
lock->lock();
value ++;
condition->signal();
lock->unlock();
}
}
第32章 常见并发问题
非死锁问题
Lu的研究表明，非死锁问题占了并发问题的大多数。它们是怎么发生的？我们如何修复？我们现在主要讨论其中两种：违反原子性（atomicity violation）缺陷和错误顺序（order violation）缺陷
死锁问题
循环等待
让锁具有偏序关系，Linux中的内存映射代码就是偏序锁。尽管如此依然容易犯错，比如当一个程序要获取多个锁，可能会lock(Mutex *mu1,Mutex *mu2*)，如果两个线程像下面这样，依然会死锁。
// thread1:
lock(lock1, lock2);
// thread2:
lock(lock2, lock1);
我们可以通过按照锁的地址顺序，来对锁进行依次加锁。
持有并等待
他需要一次性获取所有的锁，但这不利于封装
非抢占
这不现实，但是一般我们使用tryLock()来获取锁，如果失败就释放这段时间获取的所有的锁，然后重试。
top:
l1.lock();
if(!l2.trylock()) {
l1.unlock();
goto top;
}
但这会引发活锁，如果两个线程不断重复获取对方的锁，并在失败时释放自己的锁，无限循环，谁也无法获取全部锁。
互斥
避免互斥往往很难，我们一般是使用无等待数据结构，比如利用CAS等操作
通过调度
这需要了解线程需要的锁有哪些，让那些可能会共同持有一把锁的线程不重叠运行即可，但这会限制并发
检查与恢复
定期检查死锁，发现死锁则重启系统
第33章 基于事件的并发（进阶）
我们使用的基本方法就是基于事件的并发（event-based concurrency）。该方法很简单：我们等待某事（即“事件”）发生；当它发生时，检查事件类型，然后做少量的相应工作（可能是I/O请求，或者调度其他事件准备后续处理）。这就好了！
while(true) {
events = getEvents();
for (e in events) {
processEvents(e);
}
}
但是这个getEvents要怎么写呢？
select
man select
int select(int nfds, fd_set *readfds, fd_set *writefds,
fd_set *exceptfds, struct timeval *timeout);
要如何使用它呢？我们先调用select，然后使用for遍历readfds来检查是否有事件发生，一旦发生了事件我们就可以传给服务器解决了。
FDZERO() clears a set. FDSET() and FDCLR() respectively add and remove a given file descriptor from a set. FDISSET() tests to see if a file descriptor is part of the set; this is useful after select() returns.
#include <stdio.h>
#include <stdlib.h>
#include <sys/time.h>
#include <sys/types.h>
#include <unistd.h>
int main(void)
{
fd_set rfds;
struct timeval tv;
int retval;
/* Watch stdin (fd 0) to see when it has input. */
FD_ZERO(&rfds);
FD_SET(0, &rfds);
/* Wait up to five seconds. */
tv.tv_sec = 5;
tv.tv_usec = 0;
retval = select(1, &rfds, NULL, NULL, &tv);
/* Don't rely on the value of tv now! */
if (retval == -1)
perror("select()");
else if (retval)
printf("Data is available now.\n");
/* FD_ISSET(0, &rfds) will be true. */
else
printf("No data within five seconds.\n");
exit(EXIT_SUCCESS);
}
阻塞
如果在事件服务器中出现了阻塞调用，那么整个系统都将被阻塞，这是极其严重的错误！
异步IO
man aio
#include <aiocb.h>
struct aiocb {
/* The order of these fields is implementation-dependent */
int aio_fildes; /* File descriptor */
off_t aio_offset; /* File offset */
volatile void *aio_buf; /* Location of buffer */
size_t aio_nbytes; /* Length of transfer */
int aio_reqprio; /* Request priority */
struct sigevent aio_sigevent; /* Notification method */
int aio_lio_opcode; /* Operation to be performed;
lio_listio() only */
/* Various implementation-internal fields not shown */
};
/* Operation codes for 'aio_lio_opcode': */
enum { LIO_READ, LIO_WRITE, LIO_NOP };
填充这个结构体以后，我们使用异步IO，如果成功，它会立即返回。
int aio_read(struct aiocb *aiocbp);
最后我们用aid_eror来检查io是否完成
int aio_error(const struct aiocb *aiocbp);
状态管理
在多线程程序中，如果一个线程阻塞，当他苏醒时，他的状态依然保存在上下文中，但是对于基于事件的系统，就没有那个容易了，他只有一个线程，他的状态放在哪儿呢？
对于IO，解决方案是上下文信息记录在由文件描述符（fd）索引的某种数据结构（例如，散列表）中。当磁盘I/O完成时，通过数据结构恢复上下文。
更多问题
多核CPU的事件服务器必须加入锁的控制
如果发生页错误，整个服务器都将被阻塞，这个阻塞是隐式阻塞
第36章 I/O设备
操作系统架构
由于高性能总线造价高，所以内存总线很短，CPU与内存很接近。
设备协议
一个（简化的）设备接口包含3个寄存器：一个状态（status）寄存器，可以读取并查看设备的当前状态；一个命令（command）寄存器，用于通知设备执行某个具体任务；一个数据（data）寄存器，将数据传给设备或从设备接收数据。通过读写这些寄存器，操作系统可以控制设备的行为。
该协议包含4步。第1步，操作系统通过反复读取状态寄存器，等待设备进入可以接收命令的就绪状态。我们称之为轮询（polling）设备（基本上，就是问它正在做什么）。第2步，操作系统下发数据到数据寄存器。例如，你可以想象如果这是一个磁盘，需要多次写入操作，将一个磁盘块（比如4KB）传递给设备。如果主CPU参与数据移动（就像这个示例协议一样），我们就称之为编程的I/O（programmed I/O，PIO）。第3步，操作系统将命令写入命令寄存器；这样设备就知道数据已经准备好了，它应该开始执行命令。最后一步，操作系统再次通过不断轮询设备，等待并判断设备是否执行完成命令（有可能得到一个指示成功或失败的错误码）。
利用中断
有了中断后，CPU 不再需要不断轮询设备，而是向设备发出一个请求，然后就可以让对应进程睡眠，切换执行其他任务。当设备完成了自身操作，会抛出一个硬件中断，引发CPU跳转执行操作系统预先定义好的中断服务例程（Interrupt Service Routine，ISR），或更为简单的中断处理程序（interrupthandler）。
为什么要这样设计，因为IO要远比CPU慢，如果我们有一个和CPU速度一样的IO设备，我们就不需要中断，中断产生的上下文切换反而会影响系统的速度。
活锁
由于大量中断的出现，导致CPU不停的进行上下文切换，引发过载，从而无法处理任何请求，在网络传输中，如果每个包都引发一次中断，就会导致活锁，往往通过合并中断来处理这种情况。
设备在抛出中断之前往往会等待一小段时间，在此期间，其他请求可能很快完成，因此多次中断可以合并为一次中断抛出，从而降低处理中断的代价。
DMA(Direct Memory Access)
在PIO(programmed I/O)中，CPU会花费大量时间将数据传给设备，这浪费了CPU资源，如下图中的c部分
DMA的引入，CPU只需要通知DMA设备，DMA设备会帮助CPU执行c部分，当DMA处理完成以后，他会触发中断，让CPU完成接下来的任务
CPU如何与设备交互
IO指令，x86直接使用IO指令来与硬件交互。
内存映射IO，操作系统只需要将数据写入或者读取到某内存地址，即完成了硬件的交互，比如显卡在内存中就有一块映射。
第37章 磁盘驱动器
读写
磁盘驱动器由大量扇区组成，每个扇区512B，驱动器制造商保证每个扇区的写入是原子的，读取可以支持多个扇区一次性读入。
磁盘结构
圆的，每一圈都是一个磁道，每个磁道有多个扇区
匪夷所思的平均寻道时间
磁盘调度
操作系统应该如何设计磁盘的IO顺序呢？磁盘读写全部依赖磁头。磁头先定位磁道，然后定位扇区，最后读取数据。但是先读哪里，后读哪里？先写哪里后写哪里？
| 简称 | 全称 | 中文名 | 备注 | 问题 | | :--: | :-----------------------------: | :----------: | :------------------------------: | :--------------------: | | SSTF | shortest seek time first | 最短寻道时间 | 只考虑磁道，哪个IO磁道近就去哪儿 | 饥饿，无法利用几何结构 | | NBF | nearest block first | 最近块优先 | 考虑磁盘的物理距离 | 饥饿 | | SCAN | | 电梯算法 | 按电梯顺序扫描磁道 | 没有考虑旋转 | | SPTF | shortest positioning time first | 最短接入时间 | 同时考虑寻道和定位的时间 | |
第38章 廉价冗余磁盘阵列（RAID）
提出问题
磁盘很小，磁盘很慢，磁盘不可靠
RAID的简介
优点
- RAID外部接口和普通磁盘一致，可以无缝接入
- 可以通过并行读取加快IO速度
- 由于冗余的存在，RAID非常可靠
RAID内部十分复杂，包括处理器，内存和磁盘，他甚至是一个非常专业的计算机系统
RAID有三个重要的设计，RAID 0级别， RAID 1级， RAID 4/5级
RAID 0级： 条带化
无冗余，性能很高，容量最大
通过交错的方式，将块分布在各个磁盘上， 如果我们读取0-3，便可以并行读取4个磁盘
还支持更大的块
RAID 1级： 镜像
为每一个块设计一些副本
RAID 4级： 奇偶校验
RAID 5级： 旋转奇偶校验
第40章 文件系统实现
S 是超级块，储存文件系统的信息，包括文件系统中有多少inode和数据块
i 是inode的位图
d是data的位图
I 是inode的实际储存
D是data的实际储存
inode
inode是文件的低级名称，储存了文件的元数据结构，长度、权限、存放位置等。
多级索引
ext2文件系统中，inode上存放位置信息的是15个磁盘指针，为了支持更大的文件，可以引入间接指针，inode可以拥有固定数量的直接指针和间接指针，间接并不指向用户的数据块，而是指向包含更多指针的块。为什么要用这样一种设计，为什么要用这样的不平衡的树？
原因是研究表明，大多数文件非常小。
基于链表的储存
为什么不用链表来连接数据块，让一块数据块的末尾指向下一块数据块？总所周知链表的查询是O（n）的，所以如果我们想要读取文件的最后几个字节，这将直接导致我们读取几乎整个文件。
空闲空间管理
我们用位图来表示空间是否被占用。早期的文件系统使用空闲列表指针（参考操作系统内存分配算法中的空闲列表指针）
打开文件/foo/bar.txt
假设超级快已经在内存中了
graph TB
A[查询/的inode]-->B[读取一个或多个/的数据块 ]-->C[查询目录/foo的inode]-->D
D[读取一个或多个/foo/的数据块]-->E[查询文件/foo/bar.txt的inode]-->F[读取全部/foo/bar.txt的数据块]
style B fill: lightyellow
style D fill: lightyellow
style F fill: lightyellow
写入、创建文件/foo/bar
写入文件比读取复杂很多，如果要分配额外的块，写入将导致至少5次IO： 读取数据位图、写入位图、两次读取然后写入inode、最后写入真正的数据块
创建文件就更加复杂了，读取inode位图、写入inode位图、写入新的inode（为新建的文件分配inode）、写入目录数据、更新目录的inode，如果目录会增长，还要额外的IO来处理数据位图和新目录块。
接下来我们演示创建文件/foo/bar并写入3个块的数据, 可以看到里面有大量的IO
graph TB
C1[读取/的inode] --> C2[读取/的数据块]
C2-->C3[查询/foo的inode] --> C4[读取/foo的inode] --> C5[读取/foo的数据块] --> C6[把新文件的inode写入/foo]
A1[读取inode位图]--> A2[为新文件的inode分配空间]-->A3[写入inode位图]
B1[读取数据位图]--> B2[为新文件分配数据空间] --> B3[写入新文件数据]
style A1 fill: lightyellow
style B1 fill: lightyellow
style C1 fill: lightyellow
style C2 fill: lightyellow
style C4 fill: lightyellow
style C5 fill: lightyellow
style A3 fill: lightblue
style B3 fill: lightblue
style C6 fill: lightblue
如何降低IO成本
读取文件可以引入缓存，早期的文件系统引入固定大小的缓存来保存常用的块，现代系统使用动态大小来进行缓存。
写入文件可以引入缓冲，现代文件系统会将写入在内存中缓存5~30秒，然后分批写入
第41章 局部性和快速文件系统
早期的文件系统把磁盘当作内存来管理，完全忽略了磁盘昂贵的定位成本，导致性能不佳。
磁盘碎片问题，由于文件系统的不断使用，导致剩余的数据空间都是一些零星的碎片，当我们分配一个较大的文件的时候，他的数据块将散布到这些零星的位置，这将直接导致当我们读取他的时候会有很多磁盘的寻道定位现象，这严重影响了速度。
FFS
FFS将磁盘分成很多个块
利用局部性， FFS利用文件的局部性，很多应用程序在访问文件的时候，大多情况都具有局部性，当你访问了一个目录的文件以后，有很大的可能访问同目录下的其他文件，所以FFS将他们尽量组织在一同一个块
对于大型文件，FFS会将大文件散布到所有的块中
第42章 崩溃一致性：FSCK和日志
我们对文件的写入通常有很多次IO，如果在这期间操作系统崩溃了，我们该怎么办
- 定期检查整个文件系统, 但是这无法处理垃圾数据（inode指向了无效的被分配了的数据块）
早期的文件系统采用了一种简单的方法来处理崩溃一致性。基本上，它们决定让不一致的事情发生，然后再修复它们（重启时）。这种偷懒方法的典型例子可以在一个工具中找到：fsck[插图]。fsck是一个UNIX工具，用于查找这些不一致并修复它们[M86]。
- 预写日志
参考数据库系统的预写日志，先写TxBegin代表事务开始，然后写入事务的元数据，接着指向日志，最后写入TxEnd代表事务结束，如果在写入TxEnd后或者写入TxBegin前崩溃，能确保没有丢失数据，如果只有TxBegin没有TxEnd，我们可能需要启动文件系统扫描程序来检查了，Linux将这些发现的文件放入lost+found文件 夹中
- 主席树（Copy On Write）
第43章 日志结构文件系统
LFS
文件系统如何将所有写入转换为顺序写入？对于读取，此任务是不可能的，因为要读取的所需块可能是磁盘上的任何位置。但是，对于写入，文件系统总是有一个选择，而这正是我们希望利用的选择。
引入的新型文件系统Rosenblum和Ousterhout称为LFS，是日志结构文件系统（Log-structuredFile System）的缩写。写入磁盘时，LFS首先将所有更新（包括元数据！）缓冲在内存段中。当段已满时，它会在一次长时间的顺序传输中写入磁盘，并传输到磁盘的未使用部分。LFS永远不会覆写现有数据，而是始终将段写入空闲位置。由于段很大，因此可以有效地使用磁盘，并且文件系统的性能接近其峰值。
全新的Inode设计
LFS不把inode用数组的方式组织在inode块中，而是让他和他指向的文件放在一起，这将极大的加速访问。如果我们更新了文件，就一定要更新他的inode
由于indode散播到了各处，我们定位inode就有了麻烦,而且inode还一直在转移位置,LFS引入了间接层，imap，输入旧的inode，输出inode最新的位置
但是imap也需要持久化，imap放在哪？
实际上imap也和缓冲一起持久化到了磁盘。
但这又引发了问题，去哪儿寻找最新的imap？实际上在LFS中有一个固定的CR检查点区域储存着这些信息。他也会定期更新。
垃圾收集
你可能已经注意到LFS的另一个问题；它会反复将最新版本的文件（包括其inode和数据）写入磁盘上的新位置。此过程在保持写入效率的同时，意味着LFS会在整个磁盘中分散旧版本的文件结构。我们（毫不客气地）将这些旧版本称为垃圾（garbage）。
实际上有一个后台程序在负责垃圾清理
什么是垃圾？
LFS把整个磁盘分为一些块，他将一块一块的使用，并一块一块的清理，LFS在每个块中记录该块有哪些inode，垃圾收集程序只需要检查这些块的inode在imap中是否存在映射关系即可判断块是否为垃圾。
崩溃恢复和日志
CR会崩溃，块也会崩溃
CR： 维护两个CR，交替写入他们，并记录CR时间戳
块： 使用预写日志恢复
第44章 数据完整性和保护
磁盘故障
磁盘并不完美，并且可能会发生故障（有时）
潜在扇区错误 LSES
磁头碰撞导致扇区表面被破坏，或者宇宙射线导致某些位翻转。
块讹误
例如，有缺陷的磁盘固件可能会将块写入错误的位置。
类似地，当一个块通过有故障的总线从主机传输到磁盘时，它可能会讹误。
校验
奇偶校验、fletcher二阶前缀和校验、CRC校验
磁盘厂商保证每个块520字节，多的8字节存放校验和
如果没有保证就使用这个办法
错误位置写入
磁盘驱动器把数据写到错误的位置了，旧块能匹配校验和
我们增加更多的冗余，磁盘号，块号，这样就不会出现错误位置写入的问题了
写入丢失
磁盘驱动器把数据写如丢失了，旧块能匹配冗余
- 写入验证： 写入后立即读取
- 在inode中也储存校验和
第47章 分布式系统
这部分内容比较老，不如参考hadoop
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
