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
{{ message }}
This repository was archived by the owner on Apr 29, 2020. It is now read-only.
If the dir-hamt-sharded exporter finds a link that points to a subshard, it loads that subshard even if it won't contain the path we're trying to load.
The hashes generated by the hamt algorithm are stable, however, so you don't need to load the entire tree in order to find out where a given node will be, instead you can go level by level in the hamt, recreating it as you go. We use this approach in js-ipfs-mfs to add/remove DAGLinks without loading the entire graph.
This module should use a similar approach, otherwise we don't see any benefit from sharding.
The text was updated successfully, but these errors were encountered:
Since hash results are stable based on the file input, we can predict
which subshard will contain a given file based on how deep we are
in the hamt, so there's no need to traverse the entire shard to
find one file.
Fixes#9
If the
dir-hamt-sharded
exporter finds a link that points to a subshard, it loads that subshard even if it won't contain the path we're trying to load.The hashes generated by the
hamt
algorithm are stable, however, so you don't need to load the entire tree in order to find out where a given node will be, instead you can go level by level in thehamt
, recreating it as you go. We use this approach injs-ipfs-mfs
to add/remove DAGLinks without loading the entire graph.This module should use a similar approach, otherwise we don't see any benefit from sharding.
The text was updated successfully, but these errors were encountered: