4 ms·

I've seen this before but why do forges need to double space?

• rurban 4y ago
  for the old hash, plus the new hash, plus the transition tables. (new <-> old)
  • cerved 4y ago
    but I would expect the vast majority of storage to be metadata and blobs, not hashes
• avar 4y ago
  They may or may not, it's a time-space trade-off, and I'm just guessing that they'll be more likely to go for eating disk over eating CPU. There's some details on this in https://git-scm.com/docs/hash-function-transition/#_fetch https://git-scm.com/docs/hash-function-transition/#_fetch; part of the expected hash transition document assumes that you could have say a SHA-1 *.pack, but maintain both a SHA-1 and SHA-256 index into its contents. For blob objects you could serve them up as-is, but for the other types which refer to other objects (commits, trees and tags) you'd either need to store two copies and do something close to a sendfile(), or rewrite them on-the-fly as you stream them, using your SHA-1<->SHA-256 translation table. So I got a bit ahead of myself there, but none of this interop code exists yet, so the trade-offs the forges will have to make are unknown at this point.
  • vlovich123 4y ago
    Don’t blobs dominate the total disk space? It sounds like some data would double but the overall disk space usage shouldn’t be quite so dramatic (except for really small repos where it probably doesn’t matter?)
    • cerved 4y ago
      that was my intuition which is why the 2x space seemed odd