All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Schmidt <list.btrfs@jan-o-sch.net>
To: "Swâmi Petaramesh" <swami@petaramesh.org>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Example of BTRFS uglyssima performance : Bitcoin
Date: Mon, 03 Dec 2012 16:55:49 +0100	[thread overview]
Message-ID: <50BCCB85.9010905@jan-o-sch.net> (raw)
In-Reply-To: <50BC92F6.6050404@petaramesh.org>

Hi Swâmi,

On Mon, December 03, 2012 at 12:54 (+0100), Swâmi Petaramesh wrote:
> Hi folks,
> 
> My laptop is a Core i3-2310M with 4 GB RAM, running BTRFS on a 1 TB HD.
> 
> I run Ubuntu 12.10 Quantal, kernel 3.5.0-19-generic 64-bit.
> 
> I wanted to give a shot at bitcoin so I installed it from the Ubuntu
> PPA, and started getting the database from the Internet. (it's now 4.5
> GB big on disk). I assume it an SQL DB (SQlite or so ?)
> 
> My system currently has been crushing its data for more that 5 days now
> (5x24 hours) with the HD busy to the point that the system is completely
> unusable and I had to take another laptop to be able to surf the web and
> process my email. Disk LED is steadily lit, trying to switch between 2
> open windows takes 5 minutes or so...
> 
> Entering new blocks into the DB has now slowed down to the point that I
> assume that the last 6% that I miss (I'm now at 94.something %) may well
> take another couple weeks or so...
> 
> Friends running ext4 told me that the initial loading of the DB took
> them a couple hours... With BTRFS it's been 5x24 hours and counting... :-(

I've experienced exactly the same as you have with btrfs, only with ext4 instead
of btrfs: Use ubuntu (which in the default setup means you're using ecryptfs for
your /home), install the bitcoin package (which puts its files in ~/.bitcoin)
and the computer becomes very much unresponsive once bitcoin is fetching data
blocks.

Unresponsive here means that even the desktop clock misses to count a second
here and then, the mouse pointer stops reacting. Haven't looked further into
this, but I suspect ecryptfs isn't completely innocent in that stack. That said,
I suggest trying to make an ext4 partition on the very same hardware, setup
ecryptfs, mount it as ~/.bitcoin and share your findings :-)

Besides that, as Hugo told you, you can disable btrfs cow on the database files,
but given my experiences I wouldn't put too much hope into that part.

-Jan

  parent reply	other threads:[~2012-12-03 15:55 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-03 11:54 Example of BTRFS uglyssima performance : Bitcoin Swâmi Petaramesh
2012-12-03 12:09 ` Hugo Mills
2012-12-03 12:24   ` Swâmi Petaramesh
2012-12-04  2:18     ` Chris Samuel
2012-12-04  7:22       ` Swâmi Petaramesh
2012-12-03 19:13   ` Wade Cline
2012-12-03 15:55 ` Jan Schmidt [this message]
2012-12-03 16:58   ` Swâmi Petaramesh
2012-12-04  8:57     ` Sander
2012-12-03 19:32 ` Gregory Maxwell

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=50BCCB85.9010905@jan-o-sch.net \
    --to=list.btrfs@jan-o-sch.net \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=swami@petaramesh.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.