From: grarpamp <grarpamp@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Scalability issues
Date: Fri, 27 Jul 2012 15:26:35 -0400 [thread overview]
Message-ID: <CAD2Ti2_PG5yjzSMn0QVEtvd_tV0VneTq0pwdK3Fe49_daNBxrA@mail.gmail.com> (raw)
In-Reply-To: <CAPg+sBjpqqxL_GxYc+8Ry7DcXMkouO9bYi5VqOyEjj_5s0x06Q@mail.gmail.com>
> You are however using a filesystem (ZFS)
I'm aware of the memory and i386 issues, and going shopping.
> The bdb backend Bitcoin uses
> does many I/O operations, and writes them synchronously to disk, killing
> whatever caching your filesystem provides.
Sync... yes, depending on the rate/sec and size of them, that would be an
issue. "Enterprise" systems with UPS, good disk, etc assume writes are
committed upon return, eliminating need for software apps to do sync. So
I need to figure out how to turn that off?
Is sync on for everything, or just the wallet (where it could be argued as ok)?
> For those who run a large
> database on ZFS, I believe it is advised to put ZFS's intent log on a
> separate SSD-backed device, to get fast synchronous writes.
Guessing bitcoin's writes are small? So a RAM dev intent would be cheaper
and faster than SSD for that.
> on switching the bitcoin block verifier to use a different style database
> layout ("ultraprune"), which is smaller, faster, and will support pruning.
I'll try to search that. If it's anything like "delete old blocks/tx/coins that
have both been validated in the past and fully spent in the future since we
no longer need to validate further back beyond them [1]", that would be
interesting.
[1] Unless you're a historian or some usage other than casual transactions.
next prev parent reply other threads:[~2012-07-27 19:26 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-22 22:37 [Bitcoin-development] Scalability issues grarpamp
2012-07-23 7:23 ` Raphael NICOLLE
2012-07-23 7:35 ` Gregory Maxwell
2012-07-23 9:00 ` Michael Grønager
2012-07-23 15:11 ` grarpamp
[not found] ` <CAAS2fgREzk_dU0ie+YvDdRwKcTk6tk_i=a2Bb74w9uF=EwYhGA@mail.gmail.com>
2012-07-23 22:33 ` grarpamp
2012-07-27 4:20 ` grarpamp
2012-07-27 4:59 ` Gregory Maxwell
2012-07-27 5:59 ` grarpamp
2012-07-27 6:03 ` Luke-Jr
2012-07-27 6:28 ` grarpamp
2012-07-27 6:56 ` Gregory Maxwell
2012-07-27 19:37 ` grarpamp
2012-07-27 8:53 ` Andreas Petersson
[not found] ` <CAPg+sBjpqqxL_GxYc+8Ry7DcXMkouO9bYi5VqOyEjj_5s0x06Q@mail.gmail.com>
2012-07-27 9:59 ` Pieter Wuille
2012-07-27 19:26 ` grarpamp [this message]
2012-07-23 15:54 ` steve
2012-07-24 8:25 ` Michael Grønager
2012-07-24 9:18 ` Mike Hearn
2012-07-24 19:56 ` steve
2012-07-25 9:45 ` Michael Grønager
2012-07-25 14:24 ` steve
2012-07-23 22:50 ` Aidan Thornton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAD2Ti2_PG5yjzSMn0QVEtvd_tV0VneTq0pwdK3Fe49_daNBxrA@mail.gmail.com \
--to=grarpamp@gmail.com \
--cc=bitcoin-development@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox