snapshot實現(xiàn)的幾種方式

rexh7

原文來源：
http://www-128.ibm.com/developerworks/tivoli/library/t-snaptsm1/index.html

其中比較關鍵的兩種類型是Copy-on-write和redirect-on-write. 之所以說關鍵是因為，目前兩家主要的NAS設備商， EMC和Netapp各用了其中的一種。 EMC NAS是copy-on-write, Netapp是redirect-on-write. 如果說一定要在兩種實現(xiàn)方式中找點差別出來，我能想出來兩個區(qū)別，
1. copy-on-write, 對于一個寫操作， 在后臺要寫兩次， 讀若干次（讀若干次是因為RAID，不是因為SNAPSHOP）， 而redirect-on-write不需要擦除舊塊，直接再寫一個新塊， 然后修改指針。在這點上， redirect-on-write有性能上的優(yōu)勢。

2. copy-on-write可以把snapshot放在一個獨立的卷上， 有自己獨立的空間； redirect-on-write把生產(chǎn)文件系統(tǒng)的數(shù)據(jù)和snapshot的數(shù)據(jù)都放在一個卷上了，彼此犬牙交錯， 難以獨立管理snapshot所使用的實際空間。 在這點上， 我認為copy-on-write贏回一記。


下表列出其他幾種方式，嚴格意義來講， 有些是clone，不是snapshop。



Copy-on-write


Redirect-on-write


Split mirror


Log structure file architecture


Copy-on-write with background copy (IBM FlashCopy)


IBM incremental FlashCopy


Continuous data protection

Snapshot requires original copy of data
Yes: the unchanged data is accessed from the original copy
Yes: the unchanged data is accessed from the original copy
No: the mirror contains full copy of the data
Yes: the unchanged data is accessed from the original copy
Only until background copy is complete
Only until background copy is complete
No-Most implementations include a replica of the original copy
Space-efficient
Yes: in most cases space required only for changed data – exceptions such as IBM FlashCopy exist. Check with the vendor
Yes:in most cases space required only for changed data. Check with the vendor
No: requires same amount of space as original data
Yes: spaces required for the changed data
No: requires same amount of space as original data
No: requires same amount of space as original data
Yes: space required depends on the amount and frequency of changes to data when multiple point-in-time copies need to be kept.
I/O and CPU performance overhead on the system with original copy of the data
High: software based snapshot None: hardware-based snapshots (performed by the storage hardware)
High: software based snapshot None: hardware-based snapshots (Impact on the storage hardware)
Low: after mirror is split High: prior to the split to keep the mirror synchronized
High: overhead incurred in logging the writes
Low: performed by the storage hardware
Low : performed by the storage hardware
Implementation specific: Check with the vendor
Write overhead on the original copy of the data
High: first write to data block results in additional write
None: writes are directed to new blocks
None: write overhead is incurred before the split
High: writes must be logged
High: first write to data block results in additional write
High: first write to data block results in additional write
High: Each write results in a corresponding write to the storage space
Protection against logical data errors
Yes: changes can be rolled back or synched back into the original copy
Yes: changes can be rolled back or synched back into the original copy
Yes: data from the mirror must be copied. Typically slower since changes are not tracked.
Yes: the changes can be rolled back
Yes: another FlashCopy can be created in the reverse direction
Yes: another FlashCopy can be created in the reverse direction. Typically faster, since only the changed blocks are copied
Yes: changes can be synched back into the original copy
Protection against physical media failures of the original data
None: valid original copy must exist
None: valid original copy must exist
Yes: the split mirror is a full clone
None: valid original copy must exist
Full protection after background copy is complete
Full protection after background copy is complete
Implementation-specific: Check with the vendor






本文來自ChinaUnix博客，如果查看原文請點：http://blog.chinaunix.net/u/14914/showart_476561.html