Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Directory Sharding #8

Open
matheus23 opened this issue Jun 13, 2022 · 2 comments
Open

Directory Sharding #8

matheus23 opened this issue Jun 13, 2022 · 2 comments

Comments

@matheus23
Copy link
Member

In WNFS 1 in the public partition we re-used UnixFS for the directory listing, thus "borrowed" their mechanisms for sharding directories. However, that leads to more indirections and small nodes (the "userland" lived as its own UnixFS directory instead of within the WNFS directory header node), so we now inline the directory entry table in WNFS 2 directories.

In both WNFS 1 and WNFS 2 we're missing a specification for how to deal with large private directories. Ideally they should be sharded as well.

We should specify

  1. which data structure to use for sharding directories in general and
  2. in the private partition we should decide how the pieces of a sharded directory get addressed inside the HAMT and which keys are used for encrypting them.

UnixFS has decided to use HAMTs for (1). However, the downside of using HAMTs is you either balance the HAMT by hashing each directory name and thus lose range queries or you have a badly performing non-balanced tree.

We should consider search-tree based constructions like Merkle-B-Trees or Merkle Search Trees.

@matheus23
Copy link
Member Author

Hitchhiker tree to be considered: https://github.com/datacrypt-project/hitchhiker-tree

@matheus23
Copy link
Member Author

Prolly Trees may be an improvement over Merkle Search Trees, but with the same goal, via @mikeal (also see https://github.com/mikeal/prolly-trees).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant