Talk:Copy-on-write

Change COW to CoW abbrev?

ok to change article? — Preceding unsigned comment added by Krauss (talk • contribs) 12:47, 21 March 2015 (UTC)

yeah sure go for it — Preceding unsigned comment added by 31.205.30.246 (talk) 16:13, 26 November 2015 (UTC)

Done. --Dereckson (talk) 22:37, 26 October 2017 (UTC)

Two or more kinds of CoW's!

The artile as today is only about software's low memory management... But the term Copy-on-write, and an analog mechanism, can be used in another contexts. Example: filesystem and data control version in databases. --Krauss (talk) 13:53, 21 March 2015 (UTC)

Why?

If you would copy a resource and never change it, why "copy" it? You could just use it or a reference to it? And if you change it, you must make a "hard" copy of it to retain both resources. So why would you ever want COW? — Preceding unsigned comment added by 83.226.140.123 (talk) 22:40, 20 August 2017 (UTC)

The "copy" operation is more abstract than explicated here

The deep requirement is that after modifying the object, both the original object and the new object can be recovered (in the appropriate contexts).

Objects can often be represented as lists of edits. If the list is append-only (once appended, the list entry becomes immutable), you can simply replay the list to the desired depth to recover all intermediate forms.

fetch (list_of_edits, depth=1) 
fetch (list_of_edits, depth=2) 

Of course, this is not efficient for depth=1e9, so this isn't implemented for objects with high churn rates.

But do note that the list of edits is never copied (it is only ever extended in size). And also note that the referring object contains a generation integer (so the referring object is a bit more complicated than a simple pointer).

[*] Even this can be avoided, if the list has a null terminator at the front: you point to the last item you want replayed. To replay, the list is rewound to the null item at the front, then played forward to the specified element. Now the reference is a simple pointer, and list traversal is 2N instead of N.

Do we then define COW as an implementation of non-destructive edits in which some form of copy actually transpires.

My sense of this term is that most computer scientists use COW to encode the idea that you can have a lazy (deferred) algorithm to permit read sharing up until the last moment where you can't, and even here, the copy operation itself is usually small, embedded inside some pointer twizzling. — MaxEnt 09:38, 24 September 2018 (UTC)

Alternate meaning

Copy-on-Write seems to be used to refer to 2 slightly different things. This article is refering to a system where copy operations are deferred until the original or the copy is written. ie. Copy operation is defered to write time.

But the term also applies to systems like zfs, which always copy when writing. ie. Copy operation is always done at write time.

One is a property of the copy operation and the other is a property of the write operation. This article would be very misleading if someone heard about copy-on-write for zfs and looked up its meaning here. — Preceding unsigned comment added by 67.253.148.30 (talk) 22:26, 16 June 2022 (UTC)

Is that a different use by ZFS than the snapshot thing explained in this section? — voidxor 23:12, 16 June 2022 (UTC)