Frangipani论文分析总结（Lec11）

前言

1.Frangipani是一个分布式文件系统，为了使用petal——分布式虚拟硬盘而设计的。
2.Frangipani服务器互相之间不通信，只与petal和锁服务通信，这导致非常容易扩展和伸缩。
3.文章重点介绍了缓存一致性（Cache Coherence）——Frangipani服务器缓存和petal之间。
4.本文重点是三、四、七部分

一、背景

在1997年，笔记本还不流行，主要是工作站WS，也就是一个带有键盘鼠标显示器和操作系统的计算机。
随着工作站用户和文件的不断增长，需要不断增加disk（当时的存储介质）和machine，以及大量的人工管理（运维）。
作者们是一个研究所的成员，他们习惯于使用共享的基础设施，因此想让所有的工作站共享一个大容量的“disk”。

二、技术背景

1.同作者在1996年发表了《Petal: Distributed virtual disks》，一个分布式shared disk，具有如下的特点：

• 1 << 64 的地址空间，需要实际存储时，才会分配实际存储资源
• 可增加数据副本，提高可用性
• 可在线生成snapshot
• 对外提供disk接口

2.由此，同作者想把Petal的特性，发挥到上层file system中，于是设计了Frangipani。Frangipani的设计feature包括：

• 一致性：强一致（线性一致性）
• 拓展性：可透明的增加，去掉机器，尽量少的人工参与
• 容错性：可以failover
• 可在线生成snapshot

3.Petal提供了高可用的存储服务并且能够通过添加资源来实现对吞吐和容量的扩展。不过，Petal不提供协同功能或者在多个客户端间共享存储。另外，大部分的应用程序不能直接使用 Petal的接口因为 Petal面向的是磁盘而不是文件。Frangipani在 Petal之上构建了文件系统层使得在保留和扩展了 Petal有用的特性的同时对应用程序更加易用。

4.Frangipani的设计是基于 Petal提供的抽象存储服务。

三、特点

1.理想的分布式文件系统应该是可以提供一致性的文件访问、存储可以按需扩容、性能可以横向扩展、最小化人工维护成本。Frangipani就是这样的一个分布式文件系统。

2.Frangipani是一种新的可扩展分布式文件系统，将多台计算机上的磁盘集合作为共享存储池进行管理。它的目标是与已有的应用程序一起工作，比如说一个运行在工作站上的普通UNIX程序。
文件系统的数据结构，例如文件内容、inode、目录、目录的文件列表、inode和块的空闲状态，所有这些数据都存在一个叫做Petal的共享虚拟磁盘服务中。

3.Frangipani是一个用于管理disks集合与集群对应关系的分布式文件系统，其主要有以下特点：

• 所有用户看到的文件状态具有一致性。
• 可以在不打断现有server的操作和更改现有server配置的情况下添加新server。
• 系统管理员可以轻松的添加新用户，无需考虑用户的数据由哪个server管理或由哪个disk存储。
• 系统管理员可以对这个文件系统进行backup，backup可以在线执行，不需要关闭整个系统。

4.下图展示了Frangipani系统的基本层次结构，Frangipani是基于Petal系统进行搭建的。Petal系统是一个基于virtual disks的分布式存储系统，它将physical disks抽象成virtual disks，并为不同的用户提供服务。Frangipani servers通过Petal可以轻松的访问到相同的文件，并借助distributed lock service来协同不同的servers对相同文件的操作。

5. 对于Frangipani这篇论文来说，我们关注的重点主要是以下三个方面(参考）

• cache coherence
• distributed transactions
• distributed crash recovery

6.Frangipani还支持Write-Back缓存。类似于创建文件的操作可以非常快的完成，因为只需要修改本地的内存中对于磁盘的缓存。而这些修改要过一会才会写回到Petal。

7.在Frangipani的设计中，Petal作为共享存储系统存在，它不知道文件系统，文件，目录，它只是一个很直观简单的存储系统，所有的复杂的逻辑都在工作站中的Frangipani模块中。

8.所以，我们现在有了一个系统，它在工作站里面做了大量的缓存，并且文件的修改可以在本地缓存完成。这几乎立刻引出了有关设计的几个非常严重的挑战。

Frangipani的设计基本上就是用来解决相应的挑战的，我们接下来看一下会有哪些挑战：
（1）第一个挑战：缓存的强一致性。U1创建了/A，U2想立刻看到
（2）第二个挑战：原子性。两个客户端在/下都创建了文件/A 和/B，都修改了根目录，希望不要互相覆盖，即时生效。
（3）第三个挑战：崩溃恢复。一个客户端修改数据后崩溃了，不影响其他客户端数据的读取。

9.在我们接下来的讨论中，我们会关注Frangipani是如何应对这些挑战。对于Petal虚拟磁盘，它也会有许多类似的关联问题，但是它不是今天关注的重点。Petal有完全不同的，可靠的容错机制。实际上，它与我们之前讨论过的Chain-Replication非常相似。

四、Frangipani解决的挑战

1.缓存一致性

（1）第一个挑战是缓存一致性，Frangipani的缓存一致性核心是由锁保证的。

（2）除了Frangipani服务器（也就是工作站），Petal存储服务器，在Frangipani系统中还有第三类服务器，锁服务器。

（3）在锁服务器里面，有一个表单，就叫做locks。

（4）在每个工作站WS，会记录跟踪它所持有的锁，和锁对应的文件内容。所以在每个工作站中，Frangipani模块也会有一个lock表单，表单会记录文件名、对应的锁的状态和文件的缓存内容。这里的文件内容可能是大量的数据块，也可能是目录的列表。

（5）工作站对文件操作时，会标记为busy状态。
只要系统调用结束了，工作站会在内部释放锁，现在工作站不再使用那个文件。但是从锁服务器的角度来看，工作站仍然持有锁。工作站内部会标明，这是锁是Idle状态。

（6）要想缓存数据，工作站必须先持有锁，之后，才能从Petal读取数据。

（7）如果你在释放锁之前，修改了锁保护的数据，那你必须将修改了的数据写回到Petal，只有在Petal确认收到了数据，你才可以释放锁，也就是将锁归还给锁服务器。
最后再从工作站的lock表单中删除相关文件的锁的记录和缓存的数据。

（8）方法：通过lock来实现读写的一致性(仿照uinx文件的读写锁)。client对相关文件进行读的时候，会独占锁，其他用户需要对文件进行操作的时候，只能等锁释放掉，才能对文件进行操作，保证的数据的一致性。关于锁的进一步分析，见本文八、九部分。

参考

（8）工作站和锁服务器之间的缓存一致协议协议包含了4种不同的消息。本质上你可以认为它们就是一些单向的网络消息。
request、grant、revoke、release

ws——work station ls——lock server

（9）例子：ws2读取文件z时，ws1持有z文件锁。
这就是缓存一致性协议的工作流程，它确保了，直到所有有可能私底下在缓存中修改了数据的工作站先将数据写回到Petal，其他工作站才能读取相应的文件。所以，这里的锁机制确保了读文件总是能看到最新写入文件的数据。

（10）缓存一致性的优化：
a.每个工作站用完了锁之后，不是立即向锁服务器释放锁，而是将锁的状态标记为Idle。
b.Frangipani有共享的读锁（Shared Read Lock）和排他的写锁（Exclusive Write Lock）。

（11）以上机制有风险，如果我在我的工作站修改了一个文件后没有人读取它，这时，这个文件修改后的版本的唯一拷贝只存在于我的工作站的缓存或者RAM上。如果我的工作站崩溃了，并且我们不做任何特殊的操作，数据的唯一拷贝会丢失。
解决方法：工作站每隔30秒会将所有修改了的缓存写回到Petal中。所以，如果我的工作站突然崩溃了，最多丢失过去30秒的数据，这实际上是模仿Linux或者Unix文件系统的普通工作模式。

总结：锁服务中有个表单lock，记录了哪个文件被哪个工作站加锁。每个工作站也有一个表单，记录文件、锁状态、文件内容。工作站对文件操作时，锁状态busy，操作完成，不会立刻释放锁，锁状态改为idle，直到有另外的工作站来读，会将修改的文件内容写回Petal并释放锁。写完后，删除表单中对应锁记录。
保证了本地缓存和petal中的一致性。

2.原子性

（1）首先我的工作站需要获取所有我需要读写数据的锁，在完成操作之前，我的工作站不会释放任何一个锁。

（2）Frangipani使用锁实现了两个几乎相反的目标：
a.对于缓存一致性，Frangipani使用锁来确保写操作的结果对于任何读操作都是立即可见的，所以对于缓存一致性，这里使用锁来确保写操作可以被看见。
b.但是对于原子性来说，锁确保了人们在操作完成之前看不到任何写操作，因为在所有的写操作完成之前，工作站持有所有的锁。

（3）Crash with lock
a.Frangipani与其他的系统一样，需要通过预写式日志（Write-Ahead Log，WAL）实现故障可恢复的事务（Crash Recoverable Transaction）。上一篇论文Aurora中也使用过WAL。
b.工作站WS向Petal写入任何数据之前，工作站会在Petal中自己的Log列表中追加一个Log条目，这个Log条目会描述整个的需要完成的操作。只有当这个描述了完整操作的Log条目安全的存在于Petal之后，工作站才会开始向Petal发送数据。
c.工作站的Log存储在Petal，而不是本地磁盘中。

Log具体格式见本文第七部分

3.崩溃恢复

（1）当工作站持有锁，发生故障时可能会有这几种场景：
a.要么工作站正在向Petal写入Log，所以这个时候工作站必然还没有向Petal写入任何文件或者目录。
b.要么工作站正在向Petal写入修改的文件（Block)，所以这个时候工作站必然已经写入了完整的Log。
（2）第一种场景是，工作站WS1在向Petal写入任何信息之前就故障了。
petal上无log，无法恢复，我们会丢失WS1的最后几个操作，但是文件系统会与WS1开始修改之前保持一致。
（3）第二种场景是，工作站WS1向Petal写了部分Log条目。
执行恢复的工作站WS2会从Log的最开始向后扫描，直到Log的序列号不再增加，因为这必然是Log结束的位置。
工作站WS2会检查Log条目的更新内容，并向Petal执行Log条目中的更新内容。
（会有校验码之类的措施，保证日志条目完整才执行，不会执行一半的日志，事务不执行或者完整执行）
（4）第三种场景是，工作站WS1在写入Log之后，并且在写入块数据的过程中崩溃了。
执行恢复的工作站WS2并不知道WS1在哪个位置崩溃的，它只能看到一些Log条目，同样的，WS2会以相同的方式重新执行Log。
（5）更复杂的场景：如果一个工作站，完成了上面流程的步骤1，2，在释放锁的过程中崩溃了，进而导致崩溃的工作站不是最后修改特定数据的工作站。
例子：
a. 假设我们有一个工作站WS1，它执行了删除文件（d/f）的操作。
b. 之后，工作站WS2创建了同名的文件（d/f）。（Cache Coherence）
c. 在创建完成之后，工作站WS1崩溃了，所以，我们需要基于WS1的Log执行恢复，这时，可能有第三个工作站WS3来执行恢复的过程。

这里的时序表明，WS1删除了一个文件，WS2创建了一个文件，WS3做了恢复操作。
因为删除文件的Log条目仍然存在于WS1的Log中，如果不做任何额外的事情，WS3会删除这个文件（d/f）。但是实际上，WS3删除的会是WS2稍后创建的一个完全不同的文件。
解决：
Frangipani是这样解决这个问题的，通过对每一份存储在Petal文件系统数据增加一个版本号，同时将版本号与Log中描述的更新关联起来。

在Petal中，每一个元数据，每一个inode，每一个目录下的内容，都有一个版本号，当工作站需要修改Petal中的元数据时，它会向从Petal中读取元数据，并查看当前的版本号，之后在创建Log条目来描述更新时，它会在Log条目中对应的版本号填入元数据已有的版本号加1。
之后，如果工作站执行到了写数据到Petal的步骤，它也会将新的增加了的版本号写回到Petal。
所以，如果一个工作站没有故障，并且成功的将数据写回到了Petal。这样元数据的版本号会大于等于Log条目中的版本号。如果有其他的工作站之后修改了同一份元数据，版本号会更高。
WS2的修改在WS1崩溃之前，所以WS1必然已经释放了相关数据的锁。WS2获得了锁，它会读取当前的元数据可以发现当前的版本号是3，当WS2写入数据的时候，它会将版本号设置为4。

之后，当WS3执行恢复流程时，WS3会重新执行WS1的Log，它会首先检查版本号，通过查看Log条目中的版本号，并查看Petal中存储的版本号，如果Petal中存储的版本号大于等于Log条目中的版本号，那么WS3会忽略Log条目中的修改，因为很明显Petal中的数据已经被故障了的工作站所更新，甚至可能被后续的其他工作站修改了。

（6）有个比较烦人的问题就是，WS3在执行恢复，但是其他的工作站还在频繁的读取文件系统，持有了一些锁并且在向Petal写数据。WS3在执行恢复的过程中，WS2是完全不知道的。WS2可能还持有目录 d的锁，而WS3在扫描故障工作站WS1的Log时，需要读写目录d，但是目录d的锁还被WS2所持有。我们该如何解决这里的问题？
执行恢复的工作站可以直接从Petal读取数据而不用关心锁。
原因：接下来只有两种可能，要么故障了的工作站WS1释放了锁，要么没有。
如果没有的话，那么没有其他人不可以拥有目录的锁，执行恢复的工作站可以放心的读取目录数据，没有问题。
如果释放了锁，那么在它释放锁之前，它必然将有关目录的数据写回到了Petal。这意味着，Petal中存储的版本号，至少会和故障工作站的Log条目中的版本号一样大。那么这条Log条目就会被忽略。所以这种情况下，执行恢复的工作站可以不持有锁直接读取块数据，但是它最终不会更新数据。

五、架构System Structure

1.三种机器

mount Frangipani fs的机器
Petal cluster的机器
Lock Service的机器
三种机器，在不影响相互工作的情况下，理论上可以分布在任意机器上，并非图中那样的分布
比如，第一种和第二种机器可以是一台机器，第二种和第三种也不必在一台机器上。参考

2.各个组件描述

client:用户进行代码文件编写，并将数据缓存到Frangipani。
Frangipani：进行本地缓存，拉取和传送数据
petal: petal由许多petal server以及磁盘组成，一个petal server对应一个client,存储一个对应的client的文件。
petal_server：Frangipani中的数据进行保存和存取。内部含有lock_server
lock_server:读写请求锁，用来保证缓存一致性。
参考

3.两层设计

• 上层：Frangipani file system
• 下层：Petal Shared disk

4.Frangipani file system

• 运行在kernel
• 作为一个fs实现，提供标准的文件系统接口

5.安全性考虑

（1）并非所有mount了Frangipani的机器都可以访问Petal，原因是kernel不同，可能存在bug
但可以通过在已有Frangipani机器上，再搭建一层Service来实现C-S访问Frangipani，如图中的架构
（2）Frangipani 出于安全性考虑，最好只在被信任的机器上部署 Frangipani server
（3）在系统配置中，user programs和Frangipani file server部署在同一个节点当中。任何Frangipani machine都可以访问Peta virtual disk中的任意一个data block，因此Frangipani必须运行在可信的operation system中。 为了安全性保证，Frangipani server，Petal server和operation system三者必须互相认证，并且在Frangipani server和Petal server通过网络进行通信时，必须阻止恶意用户的窃听行为。参考

（4）该CS架构有以下优点：

• 将外部不可信的client和内部可信的server分割开来，外部的client machine不可以直接访问kernel中的Frangipani server。
• Frangipani server和Petal server都部署在安全的私网环境中，只允许在该环境中进行通信。 外部client和内部server通过NFS或DFS进行通信。
• 由于Frangipani部署在kernel中，因此无法快速的移植到其它版本的linux或操作系统中。client可以从一个任意版本的linux系统，访问到部署了Frangipani的linux版本从而获取服务。

6.Frangipani仍然存在的问题

• log记录会出现两次，一次在Frangipani上，一次在Petal上。
• Frangipani不知道文件的真实物理位置。
• Frangipani每次对整个文件进行加锁，而不是只对需要修改的data block加锁。

六、磁盘布局 Disk Layout

1.Frangipani使用Petal的大而稀疏的磁盘地址空间来简化其数据结构。

2.Petal虚拟磁盘有2^64字节的地址空间。并只在写入数据时才将虚拟空间地址映射到实际的物理磁盘（像内存的页式管理）。Petal同时提供了 decommit原语用来释放某个范围内的虚拟地址所关联的物理磁盘空间。

3.为了使内部的数据结构足够小，Petal会以较大的数据块来提交（commit）和回收（decommit）虚拟地址，目前的数据块大小是 64 KB.

4.为了合理的应用虚拟磁盘空间，不过多的产生内部碎片，Frangipani对虚拟磁盘空间进行了划分，具体如下图所示:

其主要包含6个区域：
(1)第一个区域用于存放共享的配置参数和管理信息。
(2)第二个区域存放日志。Frangipani将该区域划分为256个大小相同的部分，每个部分用于存放一个Frangipani server的log，因此最多可以设立256个server。
(3)第三个区域为allocation bitmaps，用于标识虚拟内存中的那些空间是空闲状态。每个server会独自占有一部分bitmap space，当一个server的bitmap space用完后，会占有新的bitmap space。
(4)第四个区域用于保存inodes，每个文件需要一个inode来记录metadata。每个inode大小为512字节，与Petal中的disk block相同，这样就不会出现多个Frangipani server访问不同的文件需要访问相同disk block的情况。 整个区域最多可以存放2^31个inodes。bitmap space和inode space之间的映射是固定的，当Frangipani新建文件时，其修改的inode space是已经在bitmap space中独占的映射区域。 需要注意的是，Frangipani server可以修改，删除，释放任意文件，但是新建文件只会在自己的inode space中。
(5)第五个区域存放small data blocks，每个block大小为4KB。每个文件的开头64KB存在在该区域。
(6)剩余区域为big daba blocks，每个block大小为1TB。每个文件除起始64KB外剩下的内存存放在该区域。参考

5.details

• 注意到每部分的大小是固定的，原因是简单，可以低成本地更改大小的配置
• logs每个Frangipani Server独占一份log，因此没有全局有序的log 每个bitmap被一个Frangipani Server独占，bitmap较多，一个bitmap被用完后，Frangipani Server会重新申请一个
• bitmap和inode有固定的映射关系，拥有bitmap的Frangipani Server只能alloc对应的inode，但可以读写任意位置的inode 文件大小的上限是16 × 4KB + 1 × 1TB，也就是一个文件，最多申请16个小data block和1个大data block，但是整个虚拟磁盘空间的划分可以灵活变动。参考

七、日志和恢复Logging and Recovery

1.Frangipani只使用metadata的write-ahead redo log进行recovery，不对user data进行记录。
即Log只包含了对于元数据的修改，比如说文件系统中的目录、inode、bitmap的分配。Log本身不会包含需要写入文件的数据，所以它并不包含用户的数据，它只包含了故障之后可以用来恢复文件系统结构的必要信息。
每个Log条目都包含了Log序列号（下图中LSN），这个序列号是个自增的数字。所以Log条目带有序列号是因为Frangipani需要检测Log的结尾。（因为是环形log）
除此之外，每个Log条目还有一个用来描述一个特定操作中所涉及到的所有数据修改的数组。数组中的每一个元素会有一个Petal中的块号（Block Number），一个版本号和写入的数据。

2.Frangipani server需要修改metadata时，其步骤如下：
（1）Frangipani server创建log并append store在自己的内存中。
（2）定时的将log通过Petal device driver发送给Petal server。
（3）Petal server将log写入Frangipani server拥有的log space。
（4）Unix update 实例会定期的将log space中的更改写入到metadata中。

注：写log流程
1.获取涉及更改的所有锁
2.关于meta data更改的事务，把所有的更改写进一条log里，放在memory或者sync进Petal
3.log写进Petal后，才可以更改Petal的实际存储

3.Petal以circular buffer（环形）的方式管理log space，当某个server的log space空间满时，会释放掉前25%的旧空间来存放新的log，在释放旧空间前需要保证其更改已经实际写入metadata。

4.当工作站从锁服务器收到了一个Revoke消息，要自己释放某个锁，它需要执行好几个步骤：
（1）首先，工作站需要将内存中还没有写入到Petal的Log条目写入到Petal中。
（2）之后，再将被Revoke的Lock所保护的数据写入到Petal。
（3）最后，向锁服务器发送Release消息。

锁服务器要我释放锁，我的工作站会先向Petal写入Log，之后再向Petal写入脏的块数据，最后才向锁服务器发送Release消息。之后，其他的工作站才能获取锁，并读取相应的数据块。这是没有故障的时候对应的流程。

5.Frangipani server的故障检测和恢复策略如下：
（1）client或lock service没有收到reply，检测到Frangipani server crash。
（2）recovery实例获取crash server的lock和log权限。
（3）recovery实例找到log的起始点和末尾点，并找出还没有处理的log进行replay。
（4）recovery实例释放lock，并清空所有log。
（5）新的Frangipani server接管工作。参考

failure detect
1.Lock Server：lease过期；或者no reply for request
2.client of Frangipani Server：no reply for request

failover步骤如下：
1.Lock Server让另一台Frangipani Server去执行Failover
2.Lock Server会赋予recovery Server之前crash Server的所有锁
3.重演合适的log（条件见上details）
4.释放crash Server的所有锁
5.其他被crash Server持有锁阻塞请求的Server可以继续工作
6.可以选择restart这台机器参考

6.只要Petal server运行正常，就可以允许任意数量的Frangipani server故障。为了能够找出log的起始点和中止点，Frangipani设定了自动增长的log sequence number。

7.由于多个Frangipani server可能会更改相同的文件，因此Frangipani通过以下机制来保证recovery的正确性：
（1）对相同数据的多个更改操作必须是串行的。 当出现write lock竞争时，只有当前server的所有update已经写入Petal disk后，才允许释放write lock。
（2）只能replay还没有写入metada的update log。 Frangipani为每个512B的metadata block设置了version number，当metablock version number < log record version number时，说明该log没有写入metadata。

注：通常情况下，先写write-ahead log，再写实际的更改内容，最后还需要把日志给擦除掉。不过Frangipani并没有最后这一步，这导致Frangipani需要额外的操作来判断该日志之前是否已经执行过了，所以论文中讲给每个block一个version number，然后每次写这个block给version number加1，来保证日志上的操作仅执行一遍。参考

（3）每个server只能有一个recovery demon来进行日志回放。

8.log会有crc校验

八、同步和缓存一致性Synchronization and Cache Coherence

1.Frangipani使用read/write lock来保证不同servers间对数据访问的一致性：
read lock：允许Frangipani server从disk中读取数据并缓存，释放read lock后cache内容失效。
write lock：允许Frangipani server从disk中读写数据，当server持有write lock时，cache内容可以和disk内容不一致。当server释放write lock或降级为read lock时，必须讲cache中的dirty data写入disk。
2.Frangipani采用分段加锁的机制，将on-disk structures分成不同的logical segments，具体策略如下：

• 每个log是一个single lockable segment。
• bitmap space本分割为多个segments。
• 每个innode和它指向的文件是一个segment。

我们将磁盘上的结构分为逻辑段，并为每个段加锁。为了避免错误的共享，我们确保一个磁盘扇区不包含一个以上可以共享的数据结构。我们将磁盘上的数据结构划分为可上锁的段，旨在保持锁的数量合理地少，但又能避免普通情况下的锁争夺，从而使锁服务不成为系统的瓶颈。

3.Frangipani采用全局顺序加锁的方式来避免死锁，当sever确定了要获得的锁后，会按照innode address对锁进行排序，依次获取。
参考

九、锁服务The Lock Service

1.lock service用于提供读写锁服务，并使用leases来处理client failure问题。每个client在获取锁时需要向lock service申请lease，lease过期时间为30秒，如果30秒内client没有向lock service重新续约，则lock service认为client已经failed。
参考

2.lock service将单个Frangipani file system的所有lock组织成一个table，每个Frangipani file system都有一个lock table。 当Frangipani file system挂载时，file system会生成一个clerk开启lock table，用于与lock server进行通信，当Frangipani file system 卸载时，clerk会关闭lock table。
（clerk在每个Frangipani file system上，用于使用锁服务）

3.clerk通过异步消息与lock server通信，消息包括：

• clerk to server: request realease
• server to clerk: grant revoke

4.lock server使用Paxos算法来备份一些全局状态信息：

• lock servers列表
• 每个lock的服务对象
• clerk list

5.当lock servers出现add或remove时，需要移动其管理的lock，具体步骤如下：
（1）丢失lock的lock server从interal state中清除这些lock信息
（2）获得lock的lock server联系所属lock table的clerk
（3）lock servers通过与clerk通信更新new lock的状态，并且clerk或者new lock所属的新server

6.当Frangipani server出现故障时，lock service会联系其它Frangipani server上的clerk来进行recovery，并在recovery结束后释放crash server的所有锁。

7.Frangipani system能够在network partition下正常运行，原因如下：
（1）如果Frangipani与lock server出现partition，lock server会认为收不到消息的Frangipani已经宕机，会启动revocery并释放所有锁。
（2）如果Frangipani与Petal server出现partition，则不能够访问disk数据。

8.一种hazard情况，当Frangipani server与lock server网络通信断开无法更新lease时，如果Frangipani server在发送write request时lease没到期，但是当Petal接收到write request时lease已经到期，write lock已经被其它server获取，就会产生写冲突。
解决方式：在发送到Petal的request上加上expiration timestamp，Petal检查这个时间是否合法。

9.lock server提供多读/单写锁。锁是粘性的；也就是说，一个客户端通常会保留一个锁，直到其他客户端需要一个冲突的锁。(回顾一下，锁服务的客户端是Frangipani服务器）。

十、添加和删除服务器Adding and Removing Servers

1.添加servers步骤：
（1）由管理人员告知servers使用哪些Petal virtual server，并与lock server建立联系。
（2）new server联系lock server获取lease并根据lease获取log space
2.删除servers步骤：
（1）直接关闭servers
（2）系统会自动进行recovery工作，写回dirty data，释放锁资源

十一、备份backup

1.Petal由自己的copy-on-write snapshot机制，且满足crash-consistent。Frangipani直接使用Petal的snapshot进行备份，snapshot包含了所有的log和数据信息，可以直接调用revocery demon进行恢复。
2.可以使用barrier global lock来实现在线备份挂载，无需调用recovery。 Frangipani提供了file system level snapshot，所有servers获取barrier global lock不再接收新的request，然后进行snapshot备份，备份结束后退出barrier。通过这种方式，snapshot可以直接作为Frangipani进行挂载，但是只能是read-only，因为Petal的snapshot只能是read only。
参考

十二、Frangipani的限制

尽管Frangipani有大量有意思且值得记住的技术，但是它对于存储系统的演进并没有什么影响。部分原因是，Frangipani的目标环境是一个小的工作组，人们坐在桌子上的工作站前共享文件。这样的环境现在还存在与某些地方，但是却不是分布式存储的主要应用场景。
真正的应用场景是一些大型的数据中心、大型网站、大数据运算，在这些场景中，文件系统的接口相比数据库接口来说，就不是那么有用了。
另一个大的场景是为大数据运算存储大的文件，但是不论对于GFS也好，还是大数据运算也好，Frangipani关注在工作站的本地缓存和缓存一致性，反而不是很有用。