All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Swâmi Petaramesh" <swami@petaramesh.org>
To: Chris Samuel <chris@csamuel.org>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Example of BTRFS uglyssima performance : Bitcoin
Date: Tue, 04 Dec 2012 08:22:07 +0100	[thread overview]
Message-ID: <50BDA49F.5090703@petaramesh.org> (raw)
In-Reply-To: <50BD5D5E.5040601@csamuel.org>

Hi Chris,

Le 04/12/2012 03:18, Chris Samuel a écrit :
> In that case maybe using an experimental filesystem that is under rapid
> development might not be a good choice, it might be better to stick to
> one of the existing stable filesystems instead.

I already made the move back and forth ext4 <-> BTRFS twice... Reading
here or there that the new (or the next) kernel is the one that indeed
fixes the bugs (3.3) or gives performance improvements (3.5), or will
make you happy this time, etc...

And each time I'm told that well, the current kernel is not so good
actually, but the next one is so much better ! So you should try the
next beta, or fetch and compile the curent mainline kernel...
...Neverending story...

All this boils down to : I do really need some of the features of BTRFS
(snapshots, checksumming, supposed high reliability...) but I also need
my computers to stay usable on a daily basis without too much hassle and
not spending 3 hours a day beta-testing or upgrading kernels... or
waiting for my mouse click to produce a result.

For getting this result I have a choice between :

- ZFS, that has proven rock-solid, feature-rich and efficient on one of
my machines for 2+ years, but is'nt part of "standard" Linux, will
probably never be, so causes issues at each distro, is tricky installing
as rootfs and which future in Linux is unclear (I don't want to have to
reinstall in 6 months a machine I install now because its filesystem
would end being unsupported...)

- BTRFS, which has already proven that it could kill all my data 3
times, which is badly slow, immature, but part of the standard kernel,
and supposed to improve at a fast pace and have its future ahead.

So basically each time I install a new system, I ask myself : ext4 ?
(but I will lack features I badly need)... ZFS ? (Excellent today, but
will I have to reinstall the machine in 6 months ?)... BTRFS (a slow
unreliable pain in the a** today, but is it this time mature enough that
this bet will make sense ?).

So well... 3.5 is a pain for databases... Now I hope I will be happy in
6 months at next Ubuntu release... If not, maybe in a year... Or a
couple years... Well...

Kind regards.

-- 
Swâmi Petaramesh <swami@petaramesh.org> http://petaramesh.org PGP 9076E32E
Ne cherchez pas : Je ne suis pas sur Facebook.


  reply	other threads:[~2012-12-04  7:22 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 [this message]
2012-12-03 19:13   ` Wade Cline
2012-12-03 15:55 ` Jan Schmidt
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=50BDA49F.5090703@petaramesh.org \
    --to=swami@petaramesh.org \
    --cc=chris@csamuel.org \
    --cc=linux-btrfs@vger.kernel.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.