总结：Frangipani: A Scalable Distributed File System

前言

   这两天在准备考试的间隙，看了6.824课程的这篇论文。可能由于刚来学校的缘故吧，还没完全掌握好节奏， 这篇论文看的不是很仔细，没有悟出很多“point”，但为了“输入必有输出”，这里就按照课程中的重点稍微总结下，以后有机会再认真研究吧。

一、总体架构

   Frangipani是一个建立在petal之上的分布式文件系统，整个系统采用分布式锁来保证一致性。其中petal是一个增量扩展、高可用可以自动管理的分布式虚拟磁盘。整个系统的架构如下图所示。

note：petal不是论文的重点，它是Frangipani利用的底层虚拟磁盘服务，可以提供一个全局统一访问的磁盘空间。

   如下图所示，Frangipani基于Petal 的特性提供文件系统的服务。这种分层结构使两者的设计实现都得到了简化。在Frangipani 中，每一个客户端也是文件系统服务器，参与文件系统的管理，可以平等地访问Petal 提供的虚拟磁盘系统，通过分布式锁实现同步访问控制。分层结构使系统具有很好的扩展性，可以在线动态地添加存储设备、增加新用户、备份等，同时系统具有很好的机制来处理节点失效、网络失效等故障，提高了系统的可用性。

   对于Frangipani这篇论文来说，我们关注的重点主要是一下三个方面

1. cache coherence
2. distributed transactions
3. distributed crash recovery

二、三个重要的问题

    Frangipani 非常好的使用了缓存的特性。即每个workstation都进行本地的缓存，同时为了提高速度，缓存的策略是write-back的，也就是只有在需要的时候会刷回硬盘，否则就一直缓存着，这在某种程度上节省了开销。

2.1 问题的引入

   举个例子，WS1（work station 1）想要创建和写/grades
   他第一步会去问Petal 读/的信息到WS1的缓存。然后增加grades entry到这个缓存里。 他不会立刻写回PETAL，这样WS1之后可以做更多修改。

   以上的流程可能会有一些问题：
（1）、对于上述流程，WS2如果要查看“/” 目录下的内容，可能get不到grades的entry，因为WS1 的write是在cache中的，并没有写到Petal中。（ caches make stale reads a serious threat）

这引入了“cache coherence”问题

（2）、如果WS1和WS2同时在同一个目录下create /a 和/b ，它们的结果会相互覆盖吗？（ there’s no central file server to sort this out!）

这引出了“atomicity”问题

（3）、如果WS1在进行创建文件（有很多步骤：allocate i-node, initialze i-node, update directory）的时候crash了，如何确保其他的WS不会看到不完整的数据呢？

这涉及到了“crash recovery” 问题。

---

2.2 cache coherence

   首先要了解的一个内容就是 在Frangipani的系统中有一个lock server（LS）的模块，用来提供全局的锁管理。

对于第一个问题，Frangipani是采用缓存一致性协议解决的。其协议主要有以下三个原则：
（1）、只有获得锁，才可以cache data
（2）、必须先获得锁，然后在可以从petal中读取
（3）、释放锁之前必须先write-back

这里介绍一下其简化的流程：
（1）、WS在进行文件的读写之时需要从LS中请求其对应的锁lock
（2）、LS在收到WS的请求之后，查看其保护的锁元信息，如果此时锁lock没被其他WS占用（或者被占用但是其lock状态是idle），则将lock分配给WS。否则返回失败。
(3)、如果WS获取到lock之后，则可以从petal中把对应的data复制到期cache中，修改之后，暂时不进行write-back，也暂时不释放锁。

（4）、此时WS2如果来请求相同的文件读写，则向LS请求对应的锁
（5）、LS查看对应的锁是否被占用并且其状态是idle，如果lock处于这个状态，则LS要求WS释放锁（revoke）
（6）、WS收到LS发来的释放锁的请求之后，先把dirty data 回写到petal中，然后释放锁。
（7）、LS返回lock给WS2
（8）、WS2收到锁授权之后，即可进行文件的读写。

以上的整个流程如下图所示。

---

2.3 Atomicity

   实现上文中所说的原子性也很简单，就是使用原子锁。一个WS要做一件事前，必须先持有对应资源的锁，当它做完了再去释放它。这样就确保了原子性。也不会发生2个文件同时创建，一个覆盖另一个的情况。（WS acquires locks on all file system data that it will modify performs operation with all locks held only releases when finished）

---

2.4 crash recovery

   除了2.1中介绍的crash 的情况外，还有一种crash是 WS 可能在持有锁的过程中die。 这种情况下怎么进行crash revocery呢？

   总的来说，Frangipani使用的机制就是WAL（write-ahead logging），简单来说就是对文件进行更新之前，需要先记录一波更新的日志。利用WAL来给crash的WS进行恢复。

   但是Frangipani中的log稍有些不同，如下所示：

1. Frangipani 每个工作站都有一个单独的日志，而不是每个分片的传统日志，这避免了日志记录瓶颈，简化了分散操作，但将更新分散在给定文件上
2. Frangipani 的日志位于共享的PETAL存储中，WS2可能会读取WS1的日志以从WS1崩溃中恢复

是不是有点懵，这个log到底存在哪？

   是这样，最初，日志条目位于WS本地内存（尚未在PETAL）中，当WS需要释放lock时会先把整个log送至petal中，然后再把dirty data更新到petal中，最后在释放锁。

   这样的话，如果WS1在持有锁的时候挂了的话，会进行下面的恢复过程：

1. WS2要求获得LS1持有的锁
2. LS发送REVOKE没有接受到WS1的响应，超时后，然后LS告诉WS2 利用WS1 crash之前写入petal 的log信息去恢复数据。
3. WS2去读WS1写的LOG 从PETAL里，随后执行这些LOG，然后告诉LS做完了，这个时候LS就可以释放WS1的锁，然后给WS2了。

所以把LOG存进共享的PETAL是非常重要的。这样就可以被别的WS去恢复。如果WS连LOG都没写进PETAL，这些操作就彻底丢失了。

---

三、总结

   随着学习的深入，慢慢发现log这个东西也挺重要，在以前的感知中，log就是记录程序运行中的一些输入输出信息，但现在觉得l很多系统，尤其是数据库系统和分布式系统中也会利用log来进行crash后数据的一致性恢复。现在理解还不是很深，以后有机会可以专门研究研究log的艺术。^_