need a safe way to truncate local datastore

[jbenet]

rm -rf $IPFS_DIR/datastore will break things

[whyrusleeping]

just yesterday i was thinking we needed an ipfs db reset command

[whyrusleeping]

@jbenet what problems exactly would just deleting the datastore directory cause?

[jbenet]

Depends on whether we store keys in it that we expect for normal operation.

—
Sent from Mailbox

On Fri, Oct 31, 2014 at 11:52 AM, Jeromy Johnson notifications@github.com
wrote:

@jbenet what problems exactly would just deleting the datastore directory cause?

Reply to this email directly or view it on GitHub:
#245 (comment)

[whyrusleeping]

this would still be nice to have:

$ ipfs repo reset
Are you sure you want to delete all of your ipfs data? [y/N]

[whyrusleeping]

this could essentially just be:

for key in node.Blockstore.KeysChan() {
    node.Blockstore.Delete(key)
}

[whyrusleeping]

Revision:

• remove all pins on all data
• iterate all blocks and remove them

[rascalking]

Hi, I'm trying to pick this up for hacktoberfest, but I cannot for the life of me figure out how to get the confirmation prompt to fire on the client side. Anyone have any pointers?

[Stebalien]

@rascalking It should be possible to do that in a PreRun function (that is run on the client).

However, I'd like to get some input from @magik6k and @schomatis as we'll need to think about the design a bit. The "just delete every block" method works fine for the flatfs datastore but will have terrible performance on badger. For that, we'd almost want to just migrate everything except the blocks to a new datastore and repalace the existing one wholesale. However, we'd need to do that in offline mode.

Thoughts? Am I being paranoid here?

[schomatis]

The "just delete every block" method works fine for the flatfs datastore but will have terrible performance on badger.

Iterating doesn't seem that expensive in Badger since we're basically doing a serial read of big files (the most expensive part would be decoding the headers of each value block) but don't quote me on this, I should run a few test to be sure.

Out of ignorance, we can't just delete the Badger DB because it's storing more than just the files that the user added, right? Some metadata?

[Stebalien]

Out of ignorance, we can't just delete the Badger DB because it's storing more than just the files that the user added, right? Some metadata?

Yes. We'd have to either just delete the blocks or migrate everything but the blocks to a new datastore and then delete the old one.

Iterating doesn't seem that expensive in Badge

IIRC, badger has behaves really poorly when deleting a ton of data. @magik6k?

[schomatis]

IIRC, badger has behaves really poorly when deleting a ton of data. @magik6k?

Actually you're right, deleting itself is not the most expensive part (although you'll be creating new delete records for every value stored) but purging the db after deleting everything (which implies a search for every delete key and many compact operations) is very cpu intensive.