深度解读原子写Atomic Write

一、从文件系统删除文件说起

文件删除操作过程比较复杂，如果简化的来讲，可以分为两步：

1. 删除该文件在文件记录表中的条目。

2. 将该文件之前所占据的空间对应的块在空间追踪bitmap中将对应的bit置0。

假设该文件的文件名非常短，尺寸也非常小，只有不到4KB，那么，上述这两个动作，就可以分别只对应一个4K的IO（如果文件系统格式化时选择4K的分块大小的话），第一个4K将更新后的记录表覆盖到硬盘对应的区域，第二个IO将更新后的bitmap的这4K部分覆盖下去。仅当这两个IO都结束时，该文件才会彻底被删除。

该是问“如果”和“为什么”的时候了。如果，文件系统将更新记录表这个IO发到了硬盘上并且成功写入，而更新bitmap的IO没有发出、或者发出了但是正在去往硬盘的路上的某处，此时系统突然断电，那会有什么结果？

放在早期的文件系统，再次重启系统之后，会进入FSCK（文件系统一致性检查及修复）阶段，也就是WinXP那个经典的蓝底黄滚动条界面。因为文件系统会维护一个dirty/clean位，在做任何变更操作之后，只要操作完成，该位就被置为clean，那么下次重启就不会进入FSCK过程，而我们上述的例子中，这两笔IO是一组不可分割的“事务（Transaction）”，一笔事务中的所有IO要么都被执行，要么干脆别被执行，结果就是这文件要么完全被删除，要么就不被删除还在那，大不了再删除一次。但是，如果一笔事务中的某个/些IO完成，另一些没完成，比如，记录表中已经看不到这个文件，但是空间占用追踪bitmap中却还记录着该文件之前被占用的空间的话，那么表象上就会看到这样的情况：双击我的电脑进去某个目录，看不到对应的文件，而右键点击硬盘属性，却发现该文件占用的空间并没有被清掉。这就产生了不一致。所以，FSCK此时需要介入，重新扫描全部的记录表，与bitmap中每个块占用与否重新匹配，最后便会将bitmap中应该被回收却没有来得及回收的bit重新回收回来。

所谓原子写，就是指一笔不可分隔开的事务中的所有写IO必须一起结束或者一起回退，就像原子作为化学变化中不可分割的最小单位一样。

二、单笔写IO会不会被原子写？

上面的场景指出，一笔事务中的多笔IO可能不会被原子写，那么单笔IO总能被原子写了吧？很不幸，也无法被原子写。原因和场景有下面三个：

2.1 上层一笔IO被分解成多笔IO

上层发出的一笔IO可能会被下层模块分解为多笔IO，这多笔IO执行之间如果断电，无法保证原子性。有多种情况可以导致一笔IO被分解，比如：

A.   IO size大于底层设备或者IO通道控制器可接受的最大IO size时，此时会由Device Driver将IO分解之后再发送给Host Driver。

B.   做了Raid，条带深度小于该IO的size，那么raid层会将该IO分解成多个IO。

2.2 外部IO控制器不会主动原子写

那么，当一笔IO（分解之后的或者未分解的，无所谓）请求到了底层，由Host Driver发送给外部IO控制器硬件的时候，外部IO控制器总可以实现原子写了吧？IO控制器硬件总不可能只把这笔IO的一部分发给硬盘执行吧？很不幸，IO控制器的确就是这样做的。比如，假设某笔写IO为32KB大小，IO控制器并不是从主存将这32KB数据都取到控制器内缓冲区才开始向后端硬盘发起IO，而是根据后端SAS链路控制器前端的buffer空闲情况，来决定从Host主存DMA多少数据进去，数据一旦进入该buffer，那么后端SAS链路控制器就会将其封装为SAS帧写到后端硬盘上。这个buffer一般只有几KB大小。所以很有可能一笔主机端的32KB的IO，在断电之前，有部分已经写入硬盘了，而剩余的部分则未被写入。虽然主机端的