快照實現了數據的邏輯保護，如果底層硬件層面的故障導致的數據丟失則無法通過快照恢復。另外，由于快照和原始卷共享數據，可能會由于存儲軟件內部的Bug引起數據的丟失（鏈接關系的損壞）。

有別于快照與原始卷共享數據，克隆（Clone）是對原始卷的完整拷貝。克隆的實現原理與快照類似，通常也是采用RoW和CoW兩種技術。采用上述兩種技術可以保證即刻創建一個克隆。但是克隆技術與快照不同的是，其后臺有任務實現數據的剝離，最終保證克隆卷的數據與原始卷的數據完全隔離。如下圖所示，最終克隆的數據甚至可以在另外一個存儲池中，實現與原始卷數據的完全隔離。這樣，即使原始卷所在的存儲池出現故障，我們依然可以通過克隆恢復原始數據。

圖片

存儲行業其實并沒有對克隆的實現做嚴格的限制，各個存儲廠商的實現也有差異。其中如華為的HyperClone實現的克隆是對原始卷的全拷貝，而Dell PowerStore的ThinClone則并非全拷貝，而只是支持寫數據的功能。

以華為的HyperClone為例，其是一個全拷貝的克隆，但是在創建之初并不能馬上保證克隆卷是原始卷數據的完全拷貝，而只能保證從訪問角度完全一致。在創建之初，會創建一個同步位圖，同步位圖記錄了哪些數據已經從原始卷同步到了克隆卷。如下圖是華為HyperClone創建后的狀態視圖，可以看到同步的進度。

圖片

克隆創建后，克隆卷本身也是一個邏輯卷，此時會建立原始卷和克隆卷的配對關系，并創建同步位圖。位圖用于標記克隆卷與原始卷之間數據的同步進展，另外，對于克隆卷的訪問也是依賴位圖的。這里位圖的功能與前面介紹的RAID1的位圖的功能有些類似的地方，大家可以類比理解一下。 

圖片

通常在存儲引擎中會有一個后臺線程進行原始卷到克隆卷數據的同步。當完成一個數據塊的同步后，克隆卷的指針和位圖都會做相應的更新。如上圖上半部分是克隆卷剛創建成功后的數據引用關系和位圖的狀態，下半部分則是完成第1個數據塊的同步后的數據引用關系和位圖的狀態。

由于克隆卷是創建后即可使用的，因此在數據的同步過程中原始卷和克隆卷都有可能有新的IO。對于讀IO來說就無所謂了，克隆卷根據引用關系讀取數據就行了；但對于寫IO則不同，無論是原始卷的寫IO還是克隆卷的寫IO都需要進行特殊的處理。如上圖所示，如果寫IO位于第1個數據塊，由于此數據已經分離，所以可以直接寫。如果寫IO位于2個數據塊（不算空洞），則需要做處理，對于來自克隆卷的IO不能按照原來的引用關系寫入數據，而是寫入新的位置，并更新指針和位圖信息，如下圖上半部分所示；對于來自原始卷的IO則需要先將數據搬移到克隆卷所在的存儲池，更新克隆卷的指針，最后才能寫入數據并更新位圖信息，如下圖下半部分所示。

在實際的產品中還要復雜一些，因為上述操作涉及多個數據塊數據的更新，任何兩步中間都有可能出現問題導致數據不一致。為了解決上述問題，通常將上述操作封裝為一個事務，以事務的方式提交所有數據的更改。

圖片

上文我們只是介紹了一種可能的實現方案，但每個廠商的實現差異起始還是挺大的。比如NetApp的FlexClone，其聲稱為基于快照的克隆。當基于原始卷創建克隆時，存儲引擎在底層會創建一個快照，并建立克隆卷與快照的關聯，大體如下圖所示。由于快照基于原始卷創建，因此快照具備了原始卷這個時間點的所有數據。而克隆建立了與該快照的關聯，當訪問克隆卷的時候就可以根據快照找到真實的數據。

圖片

快照的特性我們在前文已經詳細介紹過，原始卷更改的時候快照數據不會變化。因此，快照的存在隔離克隆卷與原始卷寫數據時的相互影響。具體而言，如果原始卷寫入了一塊新數據，由于快照的隔離作用，在克隆卷中并不會感知到這個變化。如果在克隆卷寫入新的數據也是如此，因為克隆卷跟原始卷是完全隔離的空間，自然不會影響原始卷的數據。

繼續深入克隆卷的細節，我們知道邏輯卷通過指針的方式引用數據，在創建之初，克隆卷的所有指針為空。此時如果讀數據，直接從其配對的快照相同的偏移地址讀取數據即可，如果指針有有效值，直接根據指針的位置讀取數據即可。如果寫數據，直接在克隆卷的物理空間寫數據，完成寫數據后更新指針即可。

圖片

本節我們介紹了克隆的原理，并結合主流存儲產品介紹了更多的細節。由于廠商開放的資源有限，很多細節也是作者猜測的，并不一定就是作者所描述的那樣。不過大體原理不會有大的出入，大家可以舉一反三。