2008年（8065）
分类： 服务器与存储
2008-09-15 16:27:40
用户可以采用SnapShot作为数据的在线备份，以备将来进行数据恢复时使用。用户也可以方便的把SnapShot快照备份到磁带上。无需将Filer系统下线，用户管理员就可以将最近的SnapShot快照备份到离线存储系统中。
WAFL文件系统本身就可以理解成数据块树状结构，其根部的数据结构描述了inode文件信息。这份inode文件信息则包含了对文件系统中所有inode的描述，它包含诸如空闲块图和空闲inode图等元数据信息。WAFL通过复制根数据结构创建新的数据拷贝SnapShot。因为根数据结构只有128B，并且不需要在硬盘上复制其他数据块，一个新的SnapShot几乎不耗额外的磁盘存储空间，除非用户修改或者删除文件系统中的数据。
Filer可以对一个卷组创建最多255个SnapShot快照。SnapShot快照可以通过手动或者人为预先定制策略的方式来自动创建。每一个SnapShot快照可以保存的时间取决于文件系统变动的频度。在众多应用环境中，文件系统中的大部分数据并不是每天在变化，比如一个使用10MB大小Home Directory的用户，其数据通常每天只变动100到500KB。当文件变动缓慢的时候，SnapShot可以在线保存数天甚至数周，直到他们消耗的磁盘空间过多以至用户无法接受。而另外一些文件系统中的数据则在经常不停的变动，比如CAD应用环境下，需要经常覆盖写入许多大尺寸的文件，甚至可能一两天内就会更新整个文件系统的存储内容。在此类环境下，可能只有保存数小时SnapShot的空间。
文件系统中含有包含SnapShot数据快照的子目录，允许用户自行访问稍早些时候创建的SnapShot数据快照。假设一个用户从文件系统中意外删除掉一个名为foo的文件，现在需要利用SnapShot来对其加以恢复。则可以在UNIX/NFS客户端执行以下操作：
%ls –lu .Snapshot/*/foo
-rw-r-- r--l hitz 16787 Jun 16 15:00 .Snapshot/hourly.0/foo
-rw-r-- r--l hitz 16744 Jun 16 12:00 .Snapshot/hourly.1/foo
-rw-r-- r--l hitz 16811 Jun 16 10:00 .Snapshot/hourly.2/foo
采用-U选项查看三份SnapShot数据快照，用ls命令可以显示文件foo的创建时间，要恢复foo文件，用户只需将foo不同时期的快照版本复制回当前工作目录即可。
将.snapshot/hourly.0中的文件列表，将显示创建hourly.0数据快照时包含的所有文件。.snapshot目录是隐藏目录。如果.snapshot目录可见，可以使用find命令找到更多符合要求的数据快照副本。但是类似强制删除目录的命令，如 rm –rf 对SnapShot快照目录无效，因为SnapShot文件是只读文件，所以不能删除。然而Windows用户则可以在窗口中看到一个名为~snapshot的文件夹。
能否理解WAFL文件系统是由Root Inode引导的数据块树状结构是能否理解SnapShot的关键。由此，要对这种数据块树状结构创建副本，即创建SnapShot，WAFL只需复制Root Inode。
图(a )显示了文件系统树状结构图，为简便起见，只示意出了Root Inode，没有描绘出Inode和间接数据块。
图(b)显示了WAFL如何通过对Root Inode做一个完全相同的拷贝来建立新的SnapShot快照。这个复制而成的Inode就是代表SnapShot数据块树状结构的Root Inode和实际文件系统的Root Inode结构相同。当创建了SnapShot的Inode之后，它所指向的数据块与实际文件系统Root Inode所指向的数据块完全一致。所以除了Inode本身占用的空间之外，新建的SnapShot并不会占用额外的空间。
图(c)显示了当一个用户修改数据块C时，文件系统中发生的变化。WAFL在数据块C’上面写入新的数据， 并将活动文件系统指向新的数据块。而SnapShot仍然指向原有的未经修改的数据块C。随着活动文件系统中的文件越来越多的被加以修改，SnapShot中所包含的活动文件系统不再使用的数据块也就越来越多。文件变动的频度决定了SnapShot可以在磁盘上保留的时间长短，以免耗费过多的磁盘空间。
如果将WAFL的SnapShot数据快照与IBM TransArc Episode文件系统中所采用的Fileset Clones文件集克隆产品加以比较，会立刻得到有利于证明WAFL SnapShot性能优异的结果。在IBM TransArc Episode这种UNIX兼容文件系统中，如果执行数据快照类的功能，会带来十分可观的磁盘读写I/O，并且会消耗大量的磁盘空间。
例如，一个10GB的Episode文件系统中，为描述磁盘中每一个4KB的数据块，所有的Inode会耗用320MB的磁盘存储空间。在这种性能指标下，如果需要通过复制Inode的方式创建SnapShot数据快照，将会产生320MB的磁盘I/O请求，并且消耗320MB的磁盘空间，试想一下，如果我们需要创建10个这样的SnapShot数据快照，则意味着即使活动文件系统中的数据没有发生任何变化，也要消耗掉近乎1/3的磁盘空间（320MB*10约合3.125GB）。
与之对比的是，WAFL文件系统中的情况则截然不同。如上所述，WAFL可以迅捷的创建SnapShot数据快照并且只占用极小的磁盘存储空间，即复制Root Inode所耗用的空间。举个例子，为防范系统非正常停机，WAFL需要每隔几秒钟就对文件系统创建一个一致点，即内部的SnapShot。
大多数文件系统使用位图的方式，即对每一块磁盘块使用1个数位，来标注空间数据块。如果该数位被使用了，那么意味着这个数据块是在被使用。这种机制在WAFL中并不适用，因为多个SnapShot可以同时指向一个数据块。WAFL的数据块图文件可以对每一个数据块采用32个数为来描述其路径。第0个数位记录了活动文件系统对数据块的映射，第1个数为记录了第1个SnapShot对数据块的映射，以此类推。如果一个数据块的块图文件中的任意一个数位被标注，则代表它已经被使用。
向磁盘中写入一份SnapShot数据快照的难点在于如何才能避免阻碍将发生的NFS请求，具体来说，新产生的NFS请求可能会需要更新缓存中的数据（这些数据是SnapShot的一部分）而这些数据在存入磁盘之前又恰恰是不能更改的。一种比较简单的解决方法就是延缓响应NFS请求，写入SnapShot，然后继续响应NFS请求。但是，写入SnapShot需要1秒左右的时间，对NFS请求来说，这种延迟已经是太长了，由此会带来性能的问题。
WAFL中保持SnapShot快照数据一致的技术是在高速缓存中将所有更改过的数据标明为IN_SNAPSHOT。再创建SnapShot数据快照期间的规则则是标注了IN_SNAPSHOT的数据不可被修改，而未标记的数据则不能被写入到磁盘。NFS请求可以读出所有的文件系统数据，并且可以修改未标注IN_SNAPSHOT记号的数据。而那些需要修改IN_SNAPSHOT数据的请求则必须被延缓。
为了避免阻碍NFS要求，WAFL必须尽可能迅速的处理IN_SNAPSHOT数据，为此，WAFL执行下列的步骤：
（1） 为所有包含IN_SNAPSHOT数据块的文件分配盘空间。
WAFL在两个位置高速缓存Inode数据：核心Inode数据保存在专有Inode缓存中，在磁盘缓冲中保存Inode文件。当WAFL结束对某文件分配空间后，它将新近更新的Inode信息从Inode缓存复制到相应的Inode文件磁盘缓冲中去。并且清除核心Inode数据上的IN_SNAPSHOT标记。当此步完成后，所有常规文件的数据块上均不带有IN_SNAPSHOT标记，并且大多数的NFS操作不会受到任何阻碍。因为该项操作不需要磁盘I/O，它可以很快完成。
（2）更新块图文件对每一格块图路径而言，WAFL将会把代表活动文件系统的数位标注复制成代表新SnapShot的数位标注。
（3）将所有标注了IN_SNAPSHOT的磁盘缓存信息写入到它们新近被分配的磁盘空间中去。当某一特定的磁盘缓存被清空后，WAFL就可以启动响应等着修改该缓存的NFS请求。
（4）复制Root Inode，创建代表新的SnapShot的inode，并且取消Root Inode上面的IN_SNAPSHOT标注。新SnapShot数据快照的Inode尚不可写入磁盘，直到SnapShot中所有其他数据已经被写入这条规则必须遵循，以免带来不可预料的SnapShot不一致情况。
一旦写入了新的SnapShot数据快照Inode，高速缓存中将不再包含任何IN_SNAPSHOT标注，那些被暂缓的NFS请求也可以继续处理。在正常的负载状况下，WAFL在少于1秒的时间中执行这四个步骤。另外，第一步一般能在几百分之一秒中完成，当WAFL完成这项操作后，只有很少的NFS操作将会延迟。
删除一份SnapShot数据快照也极为容易。WAFL可以简便地清除代表SnapShot快照的Root Inode，并且清除在块图路径中代表SnapShot的每一个数位标志。
