Hacker Neue

Preferences
BWStearns parent
I have file A that's in two places and I run this.

I modify A_0. Does this modify A_1 as well or just kind of reify the new state of A_0 while leaving A_1 untouched?

madeofpalk
It's called copy-on-write because when you modify A_0, it'll make a copy of the file if you write to it but not A_1.

https://en.wikipedia.org/wiki/Copy-on-write#In_computer_stor...

bsimpson
Which means if you actually edited those files, you might fill up your HD much more quickly than you expected.

But if you have the same 500MB of node_modules in each of your dozen projects, this might actually durably save some space.

_rend
> Which means if you actually edited those files, you might fill up your HD much more quickly than you expected.

I'm not sure if this is what you intended, but just to be sure: writing changes to a cloned file doesn't immediately duplicate the entire file again in order to write those changes — they're actually written out-of-line, and the identical blocks are only stored once. From [the docs](^1) posted in a sibling comment:

> Modifications to the data are written elsewhere, and both files continue to share the unmodified blocks. You can use this behavior, for example, to reduce storage space required for document revisions and copies. The figure below shows a file named “My file” and its copy “My file copy” that have two blocks in common and one block that varies between them. On file systems like HFS Plus, they’d each need three on-disk blocks, but on an Apple File System volume, the two common blocks are shared.

[^1]: https://developer.apple.com/documentation/foundation/file_sy...

jonhohle
The key is “unmodified” and how APFS knows or doesn’t know whether they are modified. How many apps write on block boundaries or even mutate just in disk data that has changed vs overwriting or replacing atomically? For most applications there is no benefit and a significant risk of corruption.

So APFS supports it, but there is no way to control what an app is going to do, and after it’s done it, no way to know what APFS has done.

mort96
For apps which write a new file and replace atomically, the CoW mechanism doesn't come into play at all. The new file is a new file.

I don't understand what makes you think there's a significant risk of corruption. Are you talking about the risk of something modifying a file while the dedupe is happening? Or do you think there's risk associated with just having deduplicated files on disk?

jonhohle
The vast majority of apps using structured data and not block oriented data formats. A major exception is databases, but common file formats that most people work with - images, text, etc. often aren't best mutated directly on disk, but rewritten either to the same file or a new file. Without some transactional capability, mutating a file directly on disk can corrupt a file if the writer fails in the middle of the write. More than a few text editors use this as their method of saving to ensure that there is never an inconsistent state of that file on disk.
bsimpson
Thanks for the clarification!
BWStearns OP
Thanks for the clarification. I expected it worked like that but couldn't find it spelled out after a brief perusal of the docs.
kdmtctl
What will happen when the original file will be deleted? Often this handled by block reference counters, which just would be decreased. How APFS handles this? Is there any master/copy concepts or just block references?
lgdskhglsa
He's using the "copy on write" feature of the file system. So it should leave A_1 untouched, creating a new copy for A_0's modifications. More info: https://developer.apple.com/documentation/foundation/file_sy...

This item has no comments currently.

Keyboard Shortcuts

Story Lists

j
Next story
k
Previous story
Shift+j
Last story
Shift+k
First story
o Enter
Go to story URL
c
Go to comments
u
Go to author

Navigation

Shift+t
Go to top stories
Shift+n
Go to new stories
Shift+b
Go to best stories
Shift+a
Go to Ask HN
Shift+s
Go to Show HN

Miscellaneous

?
Show this modal