1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <grarpamp@gmail.com>) id 1SuqBQ-0007kd-0k
for bitcoin-development@lists.sourceforge.net;
Fri, 27 Jul 2012 19:26:44 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.53 as permitted sender)
client-ip=74.125.82.53; envelope-from=grarpamp@gmail.com;
helo=mail-wg0-f53.google.com;
Received: from mail-wg0-f53.google.com ([74.125.82.53])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1SuqBN-0001Tm-Pk
for bitcoin-development@lists.sourceforge.net;
Fri, 27 Jul 2012 19:26:43 +0000
Received: by wgbfm10 with SMTP id fm10so2446259wgb.10
for <bitcoin-development@lists.sourceforge.net>;
Fri, 27 Jul 2012 12:26:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.180.99.196 with SMTP id es4mr24563423wib.18.1343417195647;
Fri, 27 Jul 2012 12:26:35 -0700 (PDT)
Received: by 10.180.78.131 with HTTP; Fri, 27 Jul 2012 12:26:35 -0700 (PDT)
In-Reply-To: <CAPg+sBjpqqxL_GxYc+8Ry7DcXMkouO9bYi5VqOyEjj_5s0x06Q@mail.gmail.com>
References: <CAD2Ti29dqCYoOMcX0zcOQnpLGCxnCjYHHqMzyyq+hvcVQ2c7nQ@mail.gmail.com>
<CAAS2fgTHrWdXHbX8oiLgnrhdC+yxL4QyPd7S4iB8RMNip_sUGg@mail.gmail.com>
<A428177D-62AD-4712-9053-47B7ED5DBC84@mac.com>
<CAD2Ti2-3sR_qusfmiStb8pzaxaB8DsPaK8a2+LWm_uL+DwvzeA@mail.gmail.com>
<CAAS2fgREzk_dU0ie+YvDdRwKcTk6tk_i=a2Bb74w9uF=EwYhGA@mail.gmail.com>
<CAD2Ti2_Pz9-SsHP49+6MKnM0er9zdAaFKDQaOgqDpju1_igd_g@mail.gmail.com>
<CAD2Ti28snGOZn9mCSALZ341TNCex23zxKHCKYztnMK3cF=jaTQ@mail.gmail.com>
<CAPg+sBjpqqxL_GxYc+8Ry7DcXMkouO9bYi5VqOyEjj_5s0x06Q@mail.gmail.com>
Date: Fri, 27 Jul 2012 15:26:35 -0400
Message-ID: <CAD2Ti2_PG5yjzSMn0QVEtvd_tV0VneTq0pwdK3Fe49_daNBxrA@mail.gmail.com>
From: grarpamp <grarpamp@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.0 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(grarpamp[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
0.6 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1SuqBN-0001Tm-Pk
Subject: Re: [Bitcoin-development] Scalability issues
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 27 Jul 2012 19:26:44 -0000
> 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.
|