Topic: Lots of disk activity on Bitcoin startup: easy fix? (Read 2506 times)
Please also consider the file fragmentation isssue. A brand new blockchain database will split in over 15000 fragments all over the disk.
You're right, patches would be welcome. Also see the bitcoin-development mailing list.
Thanks for the heads up about the mailing list. I'll try to put a patch together soon.
You're right, patches would be welcome. Also see the bitcoin-development mailing list.
For a few days now, I've noticed that every time I start the Bitcoin client, it goes nuts on disk usage for about 5 minutes and then quiets down. I finally got curious enough to find out what was going on, and it turns out that I get a large burst of disk activity every time a line "AddAddress(...)" appears in debug.log. Tracking this down, it seems to boil down to this offending line in net.cpp:
429: bool AddAddress(CAddress addr, int64 nTimePenalty)
430: {
...
444: CAddrDB().WriteAddress(addr);
...
470: }
So what's going on is that every time there's a new address, the address database is opened, a new record is stored, and then the database is closed (and presumably flushed to disk). This last part is what I think is driving BDB nuts writing stuff out.
Would it be too hard to keep a single CAddrDB object floating around (maybe lock it with a CRITICAL_SECTION), open it once on startup and close it once on shutdown? Addresses are volatile information that doesn't need to be stored *right this minute* or bitcoin will fail. They can be recreated by polling peers if need be after a crash. The code should reflect this lack of urgency to store addresses, and doing so will substantially reduce the disk usage on Bitcoin startup.
429: bool AddAddress(CAddress addr, int64 nTimePenalty)
430: {
...
444: CAddrDB().WriteAddress(addr);
...
470: }
So what's going on is that every time there's a new address, the address database is opened, a new record is stored, and then the database is closed (and presumably flushed to disk). This last part is what I think is driving BDB nuts writing stuff out.
Would it be too hard to keep a single CAddrDB object floating around (maybe lock it with a CRITICAL_SECTION), open it once on startup and close it once on shutdown? Addresses are volatile information that doesn't need to be stored *right this minute* or bitcoin will fail. They can be recreated by polling peers if need be after a crash. The code should reflect this lack of urgency to store addresses, and doing so will substantially reduce the disk usage on Bitcoin startup.
Jump to: