-
Notifications
You must be signed in to change notification settings - Fork 58
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
Bootstrap import ignores >300MB worth of already downloaded blk0001.dat #313
Comments
That's how it works. You put it in the directory, and your database goes bye bye, because it's not in any particular order (those files are just digested SSTs based on local leveldb settings). |
So I've wasted all that time & data cap downloading from peers that ground to a near-halt. And instead of overwriting the blk0001.dat file, it's just getting added filesize from where I left off >300, to now >500. Will the duplicate shit be cleared, or clearable, out of it? ETA: Maybe that series of
means it is just filling in blk0001.dat with missing blocks present in bootstrap & not appending the same ones that were already downloaded P2P? It didn't seem like the filesize started going up again until it went back to regular ProcessBlock, but I only caught it 5 seconds before the switchback. ETA2: No, that doesn't seem right, it seemed like 1K per block before bootstrap, and the file's around 572mb now with 243739 one of the latest to scroll by in the "Now" debug.log Maybe there should be a prompt on first run, then: |
I've never seen any blocks get lost as a result of importing a bootstrap.dat file, and I've imported a lot of them. It will scan the bootstrap.dat file looking for blocks you don't already have, and that will count up through all the blocks in the file. You'll see a bunch of "already have block" messages for the ones you already have. It won't re-import blocks you already have. Recent versions of Bitcoin will copy the new blocks it finds in the bootstrap.dat file into the blkNNNNN.dat files before importing them into the database, so that may explain why you're seeing the blk*.dat file(s) grow more than you expect. I forget which version of Bitcoin the last release of the CLAM client was based on, but suspect that its behavior is similar. I don't think there's any need for a warning. Importing the bootstrap.dat file doesn't delete anything, and doesn't use any bandwidth. |
Here's an example from the log of a Bitcoin bootstrap.dat I'm importing at the moment:
All the 'pre-allocating ...' messages happen as it copies the raw block data from bootstrap.dat into the various blk*.dat files, and only once it has finished doing that does it start doing the UpdateTip stuff. |
The only blk*.dat file in my ~/Library/Application Support/Clam & subdirectories is blk0001.dat debug.log does not contain "Pre-allocating" at this point, so the behavior is divergent. What was a waste of bandwidth was to download > 300 mb P2P first, then have to download the bootstrap second, which contains same > 300 mb already downloaded P2P. The quickest method should be selected first & stuck to, so you don't end up downloading stuff twice. "already have block" ran out of search results at 620695 Coming up on ProcessBlock... 1095000 |
Are you sure about this? I am a few weeks behind so I decided to downloaded
the entire bootstrap.dat file a few minutes ago to see if I would run into
the same problem.
The bootstrap.dat file didn't delete any of the current database and seems
to be working fine as you can see from "importing blocks..." on the bottom
left side of the Clamclient.
Here's a screenshot:
http://imgur.com/a/3Ja75
Unless I'm missing something here, please advise.
Thanks,
Justin
…On Wed, Aug 30, 2017 at 3:44 AM, Alwin Roe ***@***.***> wrote:
The only blk*.dat file in ~/Library/Application Support/Clam &
subdirectories is
blk0001.dat
debug.log does not contain "Pre-allocating" at this point.
What was a waste of bandwidth was to download > 300 mb P2P first, then
have to download the bootstrap second, which contains same > 300 mb already
downloaded P2P.
Coming up on ProcessBlock... 1095000
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#313 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ATLS5eRMG649eA0suhbI2_9rythIsntaks5sdSD-gaJpZM4PFJge>
.
|
Yes. That's why on my bootstrap post I have split the file into pieces each containing 10k blocks:
That way you can download just the pieces you need. |
I had tried the partial bootstrap starting range where the client left off & the "current number of blocks" went from 349,000 or so blocks down to 0. Then I tried the full bootstrap. Back to 0. Importing bootstrap shouldn't make it look like you lost 100% of your progress to date. |
Oh okay, so is it working now though?
…On Wed, Aug 30, 2017 at 1:27 PM, Alwin Roe ***@***.***> wrote:
I tried the partial bootstrap starting where the client left off & the
count went from 349,000 or so blocks down to 0. Then I tried the full one.
Back to 0.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#313 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ATLS5egBFjfSflYDUF1addwWqkeBHpQ_ks5sdamNgaJpZM4PFJge>
.
--
Justin Abraham
On Wed, Aug 30, 2017 at 1:27 PM, Alwin Roe ***@***.***> wrote:
I tried the partial bootstrap starting where the client left off & the
count went from 349,000 or so blocks down to 0. Then I tried the full one.
Back to 0.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#313 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ATLS5egBFjfSflYDUF1addwWqkeBHpQ_ks5sdamNgaJpZM4PFJge>
.
|
Define "working". bootstrap.dat is 1.84GB, blk0001.dat is 1.43GB at 48 weeks behind. |
blk0001.dat has exceeded bootstrap.dat size by 0.04 GB & counting, without being able to connect to internet. 06/01/17 scrolling past now. Waiting for it to run out of bootstrap & then I'll start downloading the segments, renaming them to bootstrap.dat & restarting after each completed. |
I pulled my cable to ensure it wasn't downloading what I'd already downloaded, and I went from 349,000 or so blocks down to 0 after putting bootstrap.dat in the same directory. WTF?!
As people either a) download the bootstrap after getting frustrated at slow P2P speed with a partial blk0001.dat or b) download & insert the bootstrap near the time of first-run, shouldn't the client be able to cat for the a) people automatically?
The text was updated successfully, but these errors were encountered: