2021 L12
Frangipani 分布式文件系统
key：
缓存一致性协议 cache coherence；
分布式锁 distributed locking；
分布式崩溃恢复 distributed crash recovery；
客户端和服务端运行在同一个节点（个人的，笔记本也算）上；
文件服务器唯一共享一个大的虚拟磁盘（Petal系统实现、多机器组成、paxos），对外暴露read和write接口；
使用场景：用在编写代码、文档，无拜占庭情况，有私人文件，也有分享/访问共享文件的能力（user2user），同一用户登录多个工作站（节点）；
场景驱动设计：
回写式缓存；（Petal前）
强一致性；
高性能；
挑战：
- 多节点间的缓存一致性；
- 多节点间的操作需保证原子性；
- 节点在操作过程中crash，及恢复；
1、 缓存文件的前提需要拥有对应的锁；
使用带锁的服务器，附带张表，记录文件及其拥有者（即资源及抢占到它的节点），
节点自己也维护一张表，记录资源的状态，是否busy，还是idle（sticky 黏锁，即可以直接对其修改，因为没有其他节点获取这份资源）；
从lock server获取锁后，本地执行完操作，将锁的状态置为idle（注意是本地状态），当其他节点同样申请这份资源时（如果原持有锁的节点没有执行完操作，即没有本地释放锁，则其他申请的节点会阻塞等待），才会写回缓存内容，并释放锁（此处就是LS上的锁了）；
2、 创建文件时，会先获取特定inode的锁，分配inode（索引节点，包含文件信息），写入，再更新文件信息入inode，释放锁（本地释放）；
- 通过顺序化解决死锁；
3、 使用WAL解决；
将磁盘的一部分划分为日志（每个日志记录都有一个校验和）；剩下为文件系统（包含inode和数据块）；
剩下就显而易见了，先将更新操作写入日志，再执行该操作（发送给Petal处理），最后释放锁； 日志：
包含需要更新的数据块（inode），版本号，例如，一个创建会有两个日志条目，对inode的更新，和对目录的更新；
版本号（单节点的版本号序列可能有跳跃，因为可能缺失的版本号在其他节点上）用于解决，恢复守护进程（recovery daemon）时，区分日志操作的先后，避免造成数据不一致；
Petal分别在每个server都有一个锁和日志；