In complement to SnapshotIQ’s read-only snapshots, OneFS also provides the ability to create writable clones of files. OneFS File Clones provides a rapid, efficient method for provisioning multiple writable copies of files. Common blocks are shared between the original file and clone, providing space efficiency and offering similar performance and protection levels across both. This mechanism is ideal for the rapid provisioning and protection of virtual machine files and is integrated with VMware's linked cloning and block and file storage APIs. This uses the OneFS shadow store metadata structure, which can reference physical blocks, references to physical blocks, and nested references to physical blocks. This is in contrast to snapshots which, as we have seen, have ditto records which reference other versions.
Figure 26. File clones
Shadow stores are hidden files, which behave differently than other files. For example:
- Reading shadow-store references might be slower than reading data directly. Specifically, reading non-cached shadow-store references is slower than reading non-cached data. Reading cached shadow-store references takes no more time than reading cached data.
- When files that reference shadow stores are replicated to another PowerScale cluster or backed up to a Network Data Management Protocol (NDMP) backup device, the shadow stores are not transferred to the target PowerScale cluster or backup device. The files are transferred as if they contained the data that they reference from shadow stores. On the target cluster or backup device, the files consume the same amount of space as if they had not referenced shadow stores.
- When OneFS creates a shadow store, OneFS assigns the shadow store to a storage pool of a file that references the shadow store. If you delete the storage pool that a shadow store resides on, the shadow store is moved to a pool occupied by another file that references the shadow store.
- OneFS does not delete a shadow-store block immediately after the last reference to the block is deleted. Instead, OneFS waits until the ShadowStoreDelete job is run to delete the unreferenced block. If a large number of unreferenced blocks exist on the cluster, OneFS might report a negative deduplication savings until the ShadowStoreDelete job is run.
- Shadow stores are protected at least as much as the most protected file that references it. For example, if one file that references a shadow store resides in a storage pool with n+2 protection and another file that references the shadow store resides in a storage pool with n+3 protection, the shadow store is protected at n+3.
- Quotas account for files that reference shadow stores as if the files contained the data referenced from shadow stores; from the perspective of a quota, shadow-store references do not exist. However, if a quota includes data protection overhead, the quota does not account for the data protection overhead of shadow stores.
Note: Clones cannot contain alternate data streams (ADS). If you clone a file that contains alternate data streams the clone will not contain the alternate data streams.