正确理解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。