Differences between current version and predecessor to the previous major change of CopyOnWrite.

Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History

Newer page: version 6 Last edited on Thursday, March 25, 2004 1:53:26 pm by AristotlePagaltzis
Older page: version 2 Last edited on Monday, October 7, 2002 7:25:23 pm by PerryLorier Revert
@@ -1 +1,5 @@
-When you fork(2), or otherwise share some memory it takes a lot of time to copy the memory causing latency, and potentially wasting memory that could be shared . The idea of CopyOnWrite is to use the [MMU] to mark a region of memory readonly , when something attempts to write to this memory it causes a processor exception to be generated , this exception then copies this page (usually 4k on Intel) . In particular after fork(2), it 's very common to execve(2) , throwing away all the memory that would have been copied
+CopyOnWrite is a concept that allows you to create initially identical incarnations of a piece of data of which you only expect a relatively minor fraction to diverge from then on nearly for free . The idea is that instead of actually copying the original, you organize it as an indirect structure, a collection of pointers to fragments of memory which the data content of the object is strewn across. Now , you can copy this object for much lower cost by copying the pointer collection instead of all of the data. Obviously you'll still need to copy the data once you need to make individual changes, but if the pointer collection includes a flag for each fragment signifying whether it is unique to that incarnation or shared between several , you can simply copy only the one fragment with data to be changed .  
+The canonical example of CopyOnWrite is the implementation of fork(2) in modern [Unix] [Kernel]s. The "pointer collection" in that case is the process 's page table. By flagging pages read-only , the [Kernel] can simply postpone copying pages until the [PageFault]s generated by the forked processes trying to write to "their" memory.  
+[FileSystem]s are also amenable to the concept of CopyOnWrite. See for a project to create such a FileSystem for [Linux]