search

tendermint / tm-db

Common database interface for various database backends for Tendermint Core and Cosmos SDK
Apache License 2.0
89 stars 136 forks source link

BoltDB cannot state sync #235

Open faddat opened 2 years ago

faddat commented 2 years ago

Bolt stores everything as a single file (iirc)

So now we get:

panic: failed to initialize database: open /Users/faddat/.osmosisd/data/snapshots/metadata.db: no such file or directory

Feedback needed, please let me know which direction to take:

creachadair commented 2 years ago

I'm not sure I understand the connection between BoltDB using a single file format and the inability to state sync. The latter seems like the first thing to tackle.

Are there an issue and/or some logs that could help us understand what's happening?

faddat commented 2 years ago

oh, sure thing!

Ok, so, currently we make everything as a folder.

So like:

/Users/faddat/.osmosisd/data/snapshots/metadata.db

is a folder. In fact maybe I can fix that now. Bolt would like a file

creachadair commented 2 years ago

Ok, so, currently we make everything as a folder.

So like:

/Users/faddat/.osmosisd/data/snapshots/metadata.db

is a folder. In fact maybe I can fix that now. Bolt would like a file

Is that behaviour specific to Osmosis? I ask, because as far as I know stock Tendermint doesn't create the database path directly—it creates the enclosing directory (e.g., $TMHOME/data), but the database path itself is left to the tm-db backend.

If the host is creating the target path as well as the enclosing directory, then probably the simplest fix is to disable the boltdb backend for that host. (That doesn't require any changes to tm-db, just presumably a build constraint for the host itself "you can't use this backend").

Perhaps better would be to have the host not try to pre-create the target path. The tm-db backends all create their working directory anyway, so it's redundant (though harmless) to do it explicitly. And then BoltDB should work out of the box. (If it doesn't already, tm-db should probably require that the implementation be responsible for creating its own targets—Badger and LevelDB definitely already do, I am not sure about Rocks).

I don't think it necessarily makes sense to delete the boltdb backend from tm-db just for this alone, though.

faddat commented 2 years ago

thanks I will look into it next week :)