trying to move my pool to an another server and after the move i'm getting `Caused by: org.rocksdb.RocksDBException: block checksum mismatch: expected 1285677076, got 3253001534 in pool/db/1568498.sst offset 0 size 1238107` i wonder if something happened to the data in transit

with the amount of old unpaid shares in the DB, i doubt anyone will mine on it anytime soon, especially as there are pools without a fee out there these days, but on general principles i'd like to keep dragging those shares along

scp is shit, the files actually come out a different size on the other side, oh joy

wanted to save effort as i have to shuffle things around through a bastion host for now

actually unrelatedly i already have that on the source side too, oof

so what can have gone wrong?

the api still gives the correct share counts out

I have had scp fail me, but not that spectacularly. rsync usually works well for me.

but based on that error, something wrong with the db (you can call me captain obvious)

i just went with piped ssh and tar, that works well - but seems the issue i kept hitting was more about filesystem accounting nuances and a red herring there's something actually wrong with the db

yeah, how do i dive in?

the downside here is that rocks db was selected based on it shitting the bed less often than other filesystem DBs while still being rather fast

but not often is not never. I should not have used it for the share db, I should have done something more reliable, like atomic file saves of plain protobufs like I did for the wallet files

the shares are intact, though

i think it's tripping up on a historical block or something

and the pool still works, but that one broken thing keeps spamming the log

ah, if you can give me the full stack trace I can make a patch that resets that list on error

it concatenates it to a degree, but here's at least a partial ```jouluk. 14, 2020 6:50:15 IP. duckutil.PeriodicThread run WARNING: Periodic thread exception java.lang.RuntimeException: org.rocksdb.RocksDBException: block checksum mismatch: expected 1285677076, got 3253001534 in pool/db/1568498.sst offset 0 size 1238107 at snowblossom.lib.db.rocksdb.RocksDBMap.put(RocksDBMap.java:59) at snowblossom.lib.db.DBMap.put(DBMap.java:19) at snowblossom.miner.plow.MrPlow.saveState(MrPlow.java:229) at snowblossom.miner.plow.MrPlow.access$200(MrPlow.java:31) at snowblossom.miner.plow.MrPlow$PlowLoop.runPass(MrPlow.java:209) at duckutil.PeriodicThread.run(PeriodicThread.java:30) Caused by: org.rocksdb.RocksDBException: block checksum mismatch: expected 1285677076, got 3253001534 in pool/db/1568498.sst offset 0 size 1238107 at org.rocksdb.RocksDB.put(Native Method) at org.rocksdb.RocksDB.put(RocksDB.java:705) at snowblossom.lib.db.rocksdb.RocksDBMap.put(RocksDBMap.java:55) ... 5 more```

or is it just that the db is so broken it's effectively read only?

looks like effectively read only, that line is saving the share state

seems to have started out of the blue like a couple of weeks ago, at least no one has been using the pool

I can make a version that saves the share state to a file and uses that rather than rocks

i have my shares and blocks as json files, so with that i could resume

as in the list of unpaid shares, which is what matters

i suppose the full history of the pool is what takes ~350MB

as the two rpc call returns are pretty tiny in comparison