You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi guys, awesome project! I have a question though.
If the nodes in the DAG are stored as immutable content addressable blobs, surely if I write a single byte to a (logical) file somewhere down in the hierarchy, then because its content hash changes, anything which references it (tree node, for example) must also be updated, and it in turn will have a new hash, and so on all the way up to the root key after the mutable namespace?
In other words, every change anywhere in a tree will cause you to have to recursively recompute a new DAG for the ancestors. Isn't this kinda expensive? Think mounting a VM disk image where lots of writes are happening? I think this is why Ivy chose a log-based approach. Or have I missed something?
[EDIT] of course, I'm assuming "commit on file close after writing" semantics
The text was updated successfully, but these errors were encountered:
Hi guys, awesome project! I have a question though.
If the nodes in the DAG are stored as immutable content addressable blobs, surely if I write a single byte to a (logical) file somewhere down in the hierarchy, then because its content hash changes, anything which references it (tree node, for example) must also be updated, and it in turn will have a new hash, and so on all the way up to the root key after the mutable namespace?
In other words, every change anywhere in a tree will cause you to have to recursively recompute a new DAG for the ancestors. Isn't this kinda expensive? Think mounting a VM disk image where lots of writes are happening? I think this is why Ivy chose a log-based approach. Or have I missed something?
[EDIT] of course, I'm assuming "commit on file close after writing" semantics
The text was updated successfully, but these errors were encountered: