4 ms·

Backup systems make tradeoffs to be space efficient (block level backups) or computationally efficient (using full file backups that have mostly IO cost.) Appl

Backup systems make tradeoffs to be space efficient (block level backups) or computationally efficient (using full file backups that have mostly IO cost.) Apple made the choice to have time machine operate with little CPU burden. While this would be a tremendously poor choice for an online storage system like SpiderOak, Dropbox, SugarSync, etc. it probably makes sense for them since it's usually working with a local external drive. I admire much of Venti's design, but last I checked, Venti didn't support recovering the space from deleted items, except by way of making a new copy of the file system.

wmf 17y ago
Apple made the choice to have Time Machine operate with little CPU burden. I don't know why, given that my CPU is a sunk cost. (Also, I suspect that Apple chose hard links instead of deltas for ease of implementation, not to save CPU cycles.) last I checked, Venti didn't support recovering the space from deleted items, except by way of making a new copy of the file system. I think the state of the art has moved on since Venti; Cumulus (and probably tarsnap) implements garbage collection to recover space. http://cseweb.ucsd.edu/~mvrable/cumulus/ http://cseweb.ucsd.edu/~mvrable/cumulus/
- rarrrrrr 17y ago
  It was definitely not chosen for ease of implementation, as Apple had to modify core file system functionality, adding support for hard links to directories as well as files in HFS+ which is fraught with peril if not implemented just right. Users just don't want a backup utility to use any significant amount of CPU and slow down their machine.
  - jrg 17y ago
    As a side note, it has always been possible (on UFS at least) to link directories. It just gets a bit messy at fsck time, and older shells get a bit confused with 'cd ..' Apple's implementation could have avoided linking directories - by creating new directories each time but always linking the files inside them - though I suspect that they decided it would be far quicker to replicate entire trees if you knew nothing in them had changed.
jf 17y ago
If I recall correctly, Venti doesn't support "recovering space from deleted items" by design - it was designed to store data on WORM drives.

wmf 17y ago

Apple made the choice to have Time Machine operate with little CPU burden. I don't know why, given that my CPU is a sunk cost. (Also, I suspect that Apple chose hard links instead of deltas for ease of implementation, not to save CPU cycles.) last I checked, Venti didn't support recovering the space from deleted items, except by way of making a new copy of the file system. I think the state of the art has moved on since Venti; Cumulus (and probably tarsnap) implements garbage collection to recover space. http://cseweb.ucsd.edu/~mvrable/cumulus/ http://cseweb.ucsd.edu/~mvrable/cumulus/

rarrrrrr 17y ago
It was definitely not chosen for ease of implementation, as Apple had to modify core file system functionality, adding support for hard links to directories as well as files in HFS+ which is fraught with peril if not implemented just right. Users just don't want a backup utility to use any significant amount of CPU and slow down their machine.
- jrg 17y ago
  As a side note, it has always been possible (on UFS at least) to link directories. It just gets a bit messy at fsck time, and older shells get a bit confused with 'cd ..' Apple's implementation could have avoided linking directories - by creating new directories each time but always linking the files inside them - though I suspect that they decided it would be far quicker to replicate entire trees if you knew nothing in them had changed.

jf 17y ago

If I recall correctly, Venti doesn't support "recovering space from deleted items" by design - it was designed to store data on WORM drives.