6.824 2020春论文阅读 Frangipani

最新推荐文章于 2024-06-12 15:38:37 发布

passenger12234

最新推荐文章于 2024-06-12 15:38:37 发布

阅读量107

点赞数

分类专栏： 6.824 与 go 文章标签：分布式分布式存储

本文链接：https://blog.csdn.net/passenger12234/article/details/123004376

版权

12 篇文章 0 订阅

订阅专栏

0. 序

尝试回想了一下这门课之前读的论文，发现除了核心的一个想法，其它论文中讨论的细节都忘得差不多了。现在读到Frangipani，觉得写一下笔记还是十分有必要的吧。

Frangipani是基于一个叫做Petal的分布式virtual disk，Petal本身具体fault tolerance, replication之类的性质，对上提供了一个单个磁盘的抽象。
另外独立的一块就是具体fault tolerance属性的lock server，向Frangipani提供分布式读写锁的服务。
每个运行Frangipani server就挂载到unix文件系统里，对上提供文件系统的抽象。

论文中描写了具体有哪些锁：每个文件或目录对应一个锁，每个server私有的log区分别对应一个锁，整个bitmap划分为多个区块，每个区块分别对应一个锁等等。
对任何目录或文件进行读写操作前，都需要获取对应的读写锁，直到脏块写回后，对应的锁才能释放。一个论文中我觉得没有说清楚的细节是，其实被Frangipani持有的锁对应两个状态，busy和idle，比如server此时正在更新该锁对应的文件的metadata以及相应的log（均在本地的dram），此时锁处于busy状态，Frangipani不能回应lock server的revoke请求，当在本地的cache中更新完文件内容后，锁处于idle状态，此时Frangipani可以写回日志，再写回具体修改的metadata，然后可以回应lock server的revoke请求。
通常情况下，Frangipani即使完成了操作也不释放锁，直到收到lock server的revoke请求，这样可以反复获取同一个锁的开销（为了保证cache coherence, Frangipani一旦释放锁就需要写回脏块，并且invalid cache）。

通常情况下，先写write-ahead log，再写实际的更改内容，最后还需要把日志给擦除掉。不过Frangipani并没有最后这一步，这导致Frangipani需要额外的操作来判断该日志之前是否已经执行过了，所以论文中讲给每个block一个version number，然后每次写这个block给version number加1，来保证日志上的操作仅执行一遍。
在课上最后老师提到version number的存在recovery software在可以在没有锁的情况下读写log中描述的block。不过从论文的描述中看，lock server在启动recovery software时会告诉它手上持有哪些锁（依据论文，lock server拥有锁的全部信息，lock server之前通过paxos协议复制它们），所以recovery software可以直接跳过那些没有持有对应锁的log（因为该log对应的操作一定已经完成了）

事实上，Frangipani并没有被广泛地使用，重要的原因在于Frangipani牺牲很大的性能(粗粒度的锁以及cache一致性协议)换来的类unix文件系统接口的特性并不是今天人们设计分布式系统时一个主要的考虑因素了。

论文中谈到一个复杂的操作（例如创建，删除文件）对应的log可能需要持有多把锁，并没有理解到论文中通过两阶段的方法来避免死锁的必要性，课上的讲解和FAQ中并没有提到这一点？

关注