Content deleted Content added
→top: rewrote the lead; it had become an incoherent jumble that failed to even state what COW consists of |
put related things together, etc. |
||
Line 11:
One major advantage of COW is the ability to use memory sparsely. Because the usage of physical memory only increases as data is stored in it, very efficient [[hash table]]s can be implemented which only use little more physical memory than is necessary to store the objects they contain. However, such programs run the risk of running out of virtual address space — virtual pages unused by the hash table cannot be used by other parts of the program{{Citation needed|date=January 2013}}. The main problem with COW at the kernel level is the complexity it adds, but the concerns are similar to those raised by more basic virtual-memory concerns such as swapping pages to disk; when the kernel writes to pages, it must copy any such pages marked copy-on-write.
== Copy-on-write in storage media ==
COW may also be used as the underlying mechanism for disk storage [[Snapshot (computer storage)|snapshots]] such as those provided by [[logical volume management]], Microsoft [[Shadow Copy|Volume Shadow Copy Service]] or file systems such as [[btrfs]] in [[Linux]].
Copy-on-write is also used in maintenance of instant snapshot on database servers like Microsoft SQL Server 2005. Instant snapshots preserve a static view of a database by storing a pre-modification copy of data when underlying data are updated. Instant snapshots are used for testing uses or moment-dependent reports and should not be used to replace backups. On the other hand, snapshots enable database back-ups in a consistent state without taking them offline.▼
The copy-on-write technique can be used to emulate a read-write storage on media that require [[wear leveling]] or are physically [[write once read many]].▼
==Other applications of copy-on-write==
Line 29 ⟶ 34:
In [[multithreaded]] systems, COW can be implemented without the use of traditional [[Lock (software engineering)|locking]] and instead use [[compare-and-swap]] to increment or decrement the internal reference counter. Since the original resource will never be altered, it can safely be copied by multiple threads (after the reference count was increased) without the need of performance-expensive locking such as mutexes. If the reference counter turns 0, then by definition only 1 thread is holding a reference so the resource can safely be de-allocated from memory, again without the use of performance-expensive locking mechanisms. The benefit of not having to copy the resource (and the resulting performance gain over traditional deep-copying) will therefore be valid in both single- and multithreaded systems.
▲Copy-on-write is also used in maintenance of instant snapshot on database servers like Microsoft SQL Server 2005. Instant snapshots preserve a static view of a database by storing a pre-modification copy of data when underlying data are updated. Instant snapshots are used for testing uses or moment-dependent reports and should not be used to replace backups. On the other hand, snapshots enable database back-ups in a consistent state without taking them offline.
▲The copy-on-write technique can be used to emulate a read-write storage on media that require [[wear leveling]] or are physically [[write once read many]].
==See also==
| |||