Raspberry pi?

no im not retarded

really man? I have had this happen on many different drives, 20+ times the past couple years. this never used to happen.

Sorry having flashbacks

god no

maybe I need to start zfs snapshotting so I can at least rollback to fix leveldb corruption

usually I can just chainstate reindex but this is the first time I've had to do a full redownload... sigh.

I had a levelDB issue myself a couple of weeks ago. FYI there's a couple of CLI options to bitcoind called -reindex and -reindex-chainstate that are probably faster than starting over.

Bitcoin Stack Exchange

How to recover corrupted Bitcoin-Core blockchain?

I recently experienced a I/O error resulting in data block corruption or index corruption cause bitcoin-qt wasn't quitting so I forced bitcoin core...

must be the sophons

I know... I hit LevelDB read failure: Corruption: block checksum mismatch: /titan/bitcoin/chainstate/612920.ldb during reindex, so I have to start over

I have talked to so many people and it happens way more often than core devs want to admit. its easy to blame hardware issues but I never seem to have any issues anywhere else.

the only thing I can think of is some ACID issue with leveldb, maybe with its configuration. not sure if it has been smoke tested.

have you tried btcd ? I found it more reliable for my simple usecase of running lnd..

It had had many consensus related issues, im good

Pis are terrible nodes, good luck

i use badgerdb to store the actual events as values in keys in my database, but they are rarely over 500k... bitcoin blocks are 2-4mb typically, honestly, they should not be stored in the DB, the differential is the age old stacking problem of slivers and chunks that used to be a big problem with networks until about 10 years ago if i was going to write a database driver for btcd i'd use badger for the indexes, and store the blocks in a flat filesystem named by the block hash... they are too big or, it might work with badger, because badger actually stacks the values in one file and the keys in another... anyway, my point here is that the entire filesystem of bitcoin's leveldb mutates so much you can't really snapshot it properly, they randomly change half the dataset for whatever reason and when you use `cp` with `-rfvpu` which retains the perms and only copies files that have been changed... it still copies all of the files because all of them have been changed so, yeah it's dumb because bitcoin values are mostly just the blocks, and the indexes are mostly just keys, so having them separated would actually make backup time-effective instead of a collossal pain in the ass

i use badgerdb to store the actual events as values in keys in my database, but they are rarely over 500k... bitcoin blocks are 2-4mb typically, honestly, they should not be stored in the DB, the differential is the age old stacking problem of slivers and chunks that used to be a big problem with networks until about 10 years ago if i was going to write a database driver for btcd i'd use badger for the indexes, and store the blocks in a flat filesystem named by the block hash... they are too big or, it might work with badger, because badger actually stacks the values in one file and the keys in another... anyway, my point here is that the entire filesystem of bitcoin's leveldb mutates so much you can't really snapshot it properly, they randomly change half the dataset for whatever reason and when you use `cp` with `-rfvpu` which retains the perms and only copies files that have been changed... it still copies all of the files because all of them have been changed so, yeah it's dumb because bitcoin values are mostly just the blocks, and the indexes are mostly just keys, so having them separated would actually make backup time-effective instead of a collossal pain in the ass

lol, the events are stored in values, the indexes in keys and yes, this would instantly solve the problem of bitcoin if i had any time spare i'd make a PR to create a btcd database driver with badger because it would probably fix most of its slow IBD

> bitcoind has always been a graet burn-in test for hardware No kidding. It's been difficult provisioning resources in my cluster to bitcoin, like it gets expensive if you run an enterprise stack. It feels like it was made to run on mostly shit hardware, more bang for the buck than consuming my expensive redundant/HA resources. I've also had some serious history with bitcoind corruption too. I had a support contract for a while and there was no shortage of DB corruption, mostly on junker hardware though.

Same! I have it on zfs RAID 1 mirrored drives, still see corruption. But the filesystem itself sees the corruption, which points to hardware which I will change. But it only happens on bitcoin blocks

point to hardware even though raid doesn’t handle it? what do you mean

most SSDs now error instead of returning garbage most of the time also if they detect a checksum error

> bitcoind is a great burn-in test for hardware Cheap external ssd's are > more bang for the buck than consuming my expensive redundant/HA resources. This is the best advice, I think.

Yeah I don't understand how you can have corruption of a specific file on mirrored drives. Does that mean both drives have corruption in the exact same place, and how likely is that? But yet, `zpool status -v` shows a blockchain block file has a CRC error.

I've got11th gen intel nuc for 110 eur, which is less than PI cost. Added some cheap ddr4 and 2tb nvme. The drive I would have to get anyway, so it's just the price of ram as extra cost, but it packs A LOT more power than the pi has.

Or it's really expensive to run any sort of HA node. I'm working on getting multiple instances running with a load balancer to achieve some software HA at the present moment

Mhhh I have a node on a pi 4 / 8gb with umbrel for 3 years and never had a single problem. Am i lucky ?

maybe, i tend to run the latest version of everything (zfs, kernel, bitcoin, etc) so its always possible I’m experiencing some new bug

Same problem here using and external SSD formatted fat32. What filesystem are you using?

zfs + internal ssd

So completely unrelated. Weird.