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

IPFS Repo Feature - Implement locks #9

Closed
daviddias opened this issue Dec 10, 2015 · 10 comments
Closed

IPFS Repo Feature - Implement locks #9

daviddias opened this issue Dec 10, 2015 · 10 comments
Labels
help wanted Seeking public contribution on this issue

Comments

@daviddias
Copy link
Member

IPFS implementations may use multiple processes, or may disallow multiple processes from using the same repo simultaneously. Others may disallow using the same repo but may allow sharing datastores simultaneously. This synchronization is accomplished via locks.

Full information: https://github.com/ipfs/specs/blob/fix-repo/repo/README.md#locks
Complete Repo Spec - https://github.com/ipfs/specs/blob/fix-repo/repo/README.md

@daviddias daviddias added the help wanted Seeking public contribution on this issue label Dec 10, 2015
@daviddias
Copy link
Member Author

I'm thinking that it would be nice to have a store, that builds on top of abstract-blob-store, introduces features as locks, but doesn't necessarily require for every blob-store implementation to be crafted by hand.

This will require things like upgrading lockfile to understand the abstract-blob-store

@daviddias
Copy link
Member Author

@whyrusleeping just to make sure I get this right, it is supposed for ipfs-repo to support more than one type of store at the same time? Looking at a regular ipfs repo, seems like datastore is using levelDB and the rest is just straight fs. (What I'm trying to understand is if I can have a clean interface for this things so that it doesn't get super complicated to make it work in the browser as well)

@daviddias
Copy link
Member Author

Ok, going to change how ipfs-repo is changed a bit, so that we support multiple types of storage mechanism depending on the type of data being stored.

I'm going to follow the diagram:
fullsizerender

With this, we can select the best datastore for each type of data, while still keeping the option of using levelDB/IndexedDB without any big changes, so it works nicely in the browser

This was referenced Dec 11, 2015
@jbenet
Copy link
Member

jbenet commented Dec 11, 2015

Some clarity on the question about stores:

go-ipfs history:

  • we started with leveldb
  • we moved blocks to flat-fs
  • we are in process of moving things off leveldb entirely (like pinset in dev0.4.0)
  • my goal is to get rid of leveldb entirely

regardless, it is the case that there is "one datastore", it's just split in two underneath the hood:

so:

  • as far as "the repo" is concerned, there's one datastore.
  • the go-ipfs fs-repo implementation uses one "mount datastore" with two on-disk datastores. this will move to just one on-disk datastore.
  • js-ipfs could get away with going straight for the "just one store". the pinset in dev0.4.0 was the hardest part to move good.

I can go through and look at what's left in leveldb, and see about moving it off. i think it may just be dht stuff at this point. (which should be objects)

@jbenet
Copy link
Member

jbenet commented Dec 11, 2015

And your diagram LGTM! (nice colors!) -- it does not mean changes on fs-repo spec or go-ipfs, right? only on how it's accessed in js-ipfs?

@daviddias
Copy link
Member Author

Nice! Thank you for bringing this clarifications into the thread, I didn't know we were moving away from two data stores.

The diagram doesn't propose any change to go-ipfs, it is just a way to deal with the current multi datastore current and enable for these to be replaced by IndexedDB so that it works in the browser.

I've been using a dev0.4.0 repo to create my tests and there is indeed levelDB stuff, I can avoid trying to parse it for now, but is it official that 0.4.0 won't have any more levelDB goodness? @jbenet @whyrusleeping

Also, I'm curious to learn why we want to remove levelDB entirely over flatfs.

@daviddias
Copy link
Member Author

-> locks + version with locks -> https://github.com/ipfs/js-ipfs-repo/pulls

@masylum
Copy link
Contributor

masylum commented Dec 11, 2015

I like the direction. 👍 @diasdavid

@jbenet
Copy link
Member

jbenet commented Dec 12, 2015

but is it official that 0.4.0 won't have any more levelDB goodness? @jbenet @whyrusleeping

dev0.4.0 wont be out of leveldb yet. if we push for it we wont ship it before xmas, and we should. that can come later. repo migrations have worked very well and not been very problematic so far. (caveat: we need to do some user research on this, with people building apps which compose go-ipfs)

@daviddias
Copy link
Member Author

I've updated the README with more documentation, architecture.

locks work, it has tests and everything, closing this issue :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Seeking public contribution on this issue
Projects
None yet
Development

No branches or pull requests

3 participants