Topic: . - page 3. (Read 39124 times)

I'd like to re-open https://github.com/znort987/blockparser/issues/1 - I'm getting the same problem when running an allBalances yesterday. Alternatively, if someone could do an allBalances for me as a precursor to solving the problem that would be greatly appreciated.

When I didn't have any blockchain files it would crash on unmapping somewhere in cleanMaps, but with blockchain data it dies on:


in initHashtables.


Valgrind output:

ext3, and pretty sure it's crashing from a null ptr. Always dies once you try to operate on the last element in vecMap.

Compiles fine but then segafaults.

There's logic issues with the mmap'ing.

Self-healing (ZFS) can make unreliable flash storage reliable.

I wish the life would be so simple. The flash storage sector is so full of cheats and fly-by-nights, that the total cost of building a reliable and long lasting Unix server simply approaches or exceeds the cost of an equivalent mainframe solution. C.f. the recent trend of using supercapacitors to power hidden write-back caches. Combined with the various wear-leveling cheats it produces failures that are extremely hard to locate. Consider this trivialized example of a circular on-disk-buffer of 3 blocks:

1 2 3
4 5 6
7 8 9

If you read it after simple reboot you'll get "7 8 9". If you read it after proper power down with super-cap discharge, you'll get "7 5 9" or "7 2 9" or various other combinations. The culprit really isn't flash technology, it is nearly always firmware problem due to its extreme complexity and trivialized testing.

There are various options available on the market, but they aren't openly advertised because they tend to use some technologies that IBM has either patented or keeps a tight contractual grip on the channel partners. e.g. SCSI disk drives with AS/400-like formatting with 520 bytes per block for 512 bytes of user data per block.

On the other hand we've never suffered a bug in a true RAM drive, possibly because of the extreme simplicity of the required firmware.

I apologise for contributing to a derailment of this thread.

If reliability is main concern, you can use RAID1 (preferably staggered in such a way that two disk in each array have different wear level). Also, larger disks will last longer before wearing.

Thank you very much. Those are primarily aimed at the "IOPS desperation" market niche. We aren't there yet. I would call our niche "rapid reboot & real reliability" for write-ahead-logging internal drive. The flash EEPROM storage is so full of misinformation about reliability that its is nearly impossible to make sensible product choices.

2112, your friends' best bet is http://www.ramsan.com/products/rackmount-ram-storage-line
But price can be quite high.

Sounds good - I'll give that a go.

Cheers

Will

blockchain.info satoshidice profit/loss seems to be a bit flaky at the moment - so right now to work out my profit/loss I'm exporting my transactions then pulling tx info from blockchain.info for each of my transactions and working out if it contains a 1dice* address then assuming that's a bet and adding/removing from the total.

it would be nice to do this using your tool - so supplied with a list of all my addresses, parse blockchain for tx with either { my address } -> { 1dice* } or { 1dice* } -> { my address }

Is this possible?

Will

Thanks. gcc now at  4.6.3.

However, now receive -


I believe I do have openssl compiled correctly with ECDSA.

Is this worth pursuing?

I know this is developed under Ubuntu, but it would be nice to have working on RH type distros.

I have openssl with ecdsa working, but blockparser won't compile -


Is this something worth pursuing further?

Would it be possible to dig out what percentage of coins have ever been moved for any 2016 block period?

I would be interested in how many of the early coins have never been moved.

edit: ok, just found your post: https://bitcointalksearch.org/topic/z-98641  [2 Million unspent...]

This is nice. One feature I would like to see is the creation of a table that stores public key to balance pairs, and keeps updating from time to time. This way you can quickly look up the balance of an address. If I have time, I may use this code to do this, and I'll add it to my wallet parser: https://github.com/piratelinux/cwallet

Thanks. Unfortunately this is still a flash drive with RAM cache and still susceptible to write amplification abuse. Thus far we haven't found anything better than discontinued ACARD ANS-9010 (64GB with battery backup) and some other custom-made solutions.

http://www.ddrdrive.com - it was designed for ZFS ZIL, and the RAM is backed by SLC NAND flash. It was priced $2000 when it launched ~3 years ago. The price has probably gone down a lot, but it is still way more than 10x the price per GB than system's RAM.

Part of the reason prices are so high is because there are so few vendors, so there is practically no competition.

Please pardon me for jumping in, but please post the links to those overpriced hardware RAM drives. My friends in IT operations are on the market and have hard time sourcing devices that don't wear out are reasonably non-volatile and can survice reboot/reconfig/reload of the OS.

The hardware ram drives I know use old DDR2 memory. Maybe there are new ones that are horribly overpriced. Or I'll look around to see if someone has made one. The one I know used to use a SATA cable to emulate a hard drive. Real ram inside the motherboard is obviously going to work a lot faster.

Do it, 32GB only costs $160, assuming you already have a machine with a motherboard supporting 4 x 8GB DDR3.
But don't buy hardware ram drives. They are all horribly overpriced, as in 10x more expensive per GB, or more.