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 ) 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 ; 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: References: Date: Fri, 27 Jul 2012 15:26:35 -0400 Message-ID: From: grarpamp 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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.