123 entries in 0.466s
dorion: after restarting with -caneat, bitcoind
eatblock 588012.blk returns: error: {"code": -2, "message":"Safe mode: WARNING: Displayed transactions may not be correct! You may need to upgrade, or other node may need to upgrade."
mp_en_viaje: girlattorney, you can just use
eatblock, have it synced from known-good chain in a day or so
mod6: my personal node corrupted again. I'll be pulling it off the list of nodes until it's rebuilt... takes about 10 days with
eatblock.
mod6: i think i'm just gonna cutblock all the blk*.dat files, and
eatblock 'em.
mod6: for instance, i have a R610 running with ssd, and when doing
eatblock (sucking in all the blocks cut up via cutblk), I can process like 15k-20k blocks per day. more importantly, the IO timings are WAAAAAY lower.
mod6: i basically did a recent full sync with nothing but feeding into
eatblock, from cut blk files, took ~6 days iirc.
mod6: however, i might try a hand at keeping all but the most recent blk###.dat files, cutting them up with blkcut, then feeding them back in with
eatblock.
a111: Logged on 2017-08-11 00:18 mircea_popescu:
http://btcbase.org/log/2017-08-10#1696875 << it is conceivable you can reuse prb blockchains, if you care. not that there's anything wrong with rechecking the chain if oyu're in no hurry. expect a coupla months tho. and i suppose look into
eatblock etc while at it.
mod6: Wasn't a total loss this month being able to do some FG testing and
eatblock testing.
mod6: It wouldn't take much more effort to add the AcceptBlock values into the trb_offline_eatblock.png if that's wanted.
mod6: my re-run of
eatblock is complete... will re-post stats etc here in a bit
mod6: shinohai: sure will do. it's just the
eatblock test. once it's complete, i'll re-run all of the charts & metrics
mod6: In other news, my
eatblock re-test is at 433K+ & into blk0042; not much more to go there...
mod6: also,
eatblock test is no around 411K bocks and into blk0034... so should be done in a day or two.
mod6:
Eatblock test upto 363K+ blocks and into blk0019.
mod6: Update:
eatblock now @ 353K+ blocks, into blk0017.
mod6:
eatblock is upto 235K+ blocks.
mod6: alright, mircea_popescu & asciilifeform ; full offline
eatblock test is running again
mod6: i'm up for a full re-
eatblock. just want to make sure I'm not missing anything this time :]
mircea_popescu: nevermind the bunch of these, i want the whole
eatblock'd blockchain.
mircea_popescu: asciilifeform possibly time to re-do this whole
eatblock instrumentation with a per-line timing profiler.
mod6: I think I just reached the end of my
eatblock test...
mod6: the offline
eatblock of entire chain (or at least what I had before was getting blackholed)
mod6: update on offline-
eatblock: 431K+ and into blk0041
shinohai imagines
eatblock pausing .... "Please insert disk 30 ...."
trinque: davout: there is also
eatblock davout: also i'm getting a "Flushing wallet.dat" after each
eatblock, eats ~50ms each time
davout: i'm still curious what would make this kind of setup where i script "prb dumpblock | hex2bin | trb
eatblock" much faster than syncing from network if the bottleneck is indeed the block verification?
mod6: sure, i think going block -> certainly fits into the same paradigm as
eatblock/dumpblock.
a111: Logged on 2015-06-30 19:12 ascii_field: in other nyooz, 'dumpblock' for the sums.txt.gz mircea_popescu set 0..n and subsequent '
eatblock' in brand-new stator - works
phf: it seems like a cool profiling target, how long it takes to
eatblock entire chain across different ssds on some test hardware
phf: ascii_field: saw it of course. i wanted to cut out the whole blkcut -> block ->
eatblock roundtrip, plus i want to see how fast it can eat at saturation. which is surprisingly not fast at all
ascii_field: '
eatblock' does exactly one shot of eating a block.
assbot: Logged on 24-09-2015 22:12:13; ascii_field: (
eatblock is a locking operation)
phf: i don't have intuition for complete
eatblock time, but 3 weeks does sound like surprisingly long time, even with all the checks enabled
gernika: Right. So I made it to 368xxx and got stuck on the large block syncing from one of your nodes over the network. I then (probably) had a bad shutdown and corrupted the db. I then used
eatblock to sync from what I had on disk up to that point.
ascii_field: the correct way to use
eatblock is with dumpblock coming from an already synced LOCAL node.
ascii_field: as in, where did the blocks fed to '
eatblock' come from ?
assbot: Logged on 24-09-2015 19:30:42; gernika: Friend is claiming he can do a full sync in 6-8 hours using the phoundation client (non-ssd), while it took my OpenBSD box 3 weeks using
eatblock. Not sure what I'm doing wrong.
gernika: Friend is claiming he can do a full sync in 6-8 hours using the phoundation client (non-ssd), while it took my OpenBSD box 3 weeks using
eatblock. Not sure what I'm doing wrong.
☟︎ mod6: you know... actually, i think im still on to something here... i just didn't mean 'asciilifeform_and_now_we_have_eatblock.vpatch', ... but im going back over all of this again. the paste above & stuff was brain fart.
mod6: ;;later tell asciilifeform I've been testing/looking at 'v' quite a bit. Re-implementing on my own for better/full understanding (since I'm not a python guy). I'm confused about why here 'asciilifeform_and_now_we_have_eatblock.vpatch' is not listed as a descendant of mod6_fix_dumpblock_params.vpatch :
http://dpaste.com/08X2Q6P.txt gernika: ascii_field so do something like bitcoind dumpblock i | bitcoind -datadir=somewhereelse
eatblock i?
mod6: Have a bunch of automated tests (cucumber) that now builds the new test bundle, verify, check binary, test -connect, dumpblock,
eatblock. ima post a log here in just a bit.
mod6: ascii only has 3 patches post blockdump (
eatblock, rm testnet, verifyall)
phf: ascii_field: i don't think that's the case. i changed block processing to return false when the block is bastard, and
eatblock started returning false for those.
decimation: I'm syncing stator+
eatblock+dumpblock on some node, just cleared 200k blocks
ben_vulpes: dumpblock,
eatblock, exposure of the ancient blockchain is quiet now?