Veritas Storage Foundation 5.1 SP1 Advanced Features Administrator"s Guide (5900-1503, April 2011)

with FileSnaps is closer to that of an allocating write than that of a traditional
copy-on-write.
In disk layout Version 8, to support block or extent sharing between the files,
reference counts are tracked for each shared extent. VxFS processes reference
count updates due to sharing and unsharing of extents in a delayed fashion. Also,
an extent that is marked shared once will not go back to unshared until all the
references are gone. This is to improve the FileSnap creation performance and
performance of data extent unsharing. However, this in effect results in the shared
block statistics for the file system to be only accurate to the point of the processing
of delayed reclamation. In other words, the shared extent statistics on the file
system and a file could be stale, depending on the state of the file system.
Creating FileSnaps
A single thread creating FileSnaps of the same file can create over ten thousand
snapshots per minute. FileSnaps can be used for fast provisioning of new virtual
machines by cloning a virtual machine golden image, where the golden image is
stored as a file in a VxFS file system or Veritas Storage Foundation Cluster File
System (SFCFS) file system, which is used as a data store for a virtual environment.
Concurrent I/O to FileSnaps
FileSnaps design and implementation ensures that concurrent reads or writes to
different snapshots of the same file perform as if these were independent files.
Even though the extents are shared between snapshots of the same file, the sharing
has no negative impact on concurrent I/O.
Copy-on-write and FileSnaps
Veritas File System (VxFS) supports an option to do lazy copy-on-write when a
region of a file referred to by a shared extent is overwritten. A typical copy-on-write
implementation involves reading the old data, allocating a new block, copying or
writing the old data to the new block synchronously, and writing the new data to
the new block. This results in a worst case possibility of one or more allocating
transactions, followed by a read, followed by a synchronous write and another
write that conforms to the I/O behavior requested for the overwrite. This sequence
makes typical copy-on-write a costly operation. The VxFS lazy copy-on-write
implementation does not copy the old data to the newly allocated block and hence
does not have to read the old data either, as long as the new data covers the entire
block. This behavior combined with delayed processing of shared extent accounting
makes the lazy copy-on-write complete in times comparable to that of an allocating
295Administering FileSnaps
Creating FileSnaps