lkml.org 
[lkml]   [2010]   [Aug]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: BTRFS: Unbelievably slow with kvm/qemu
On 20100831 14:46, Mike Fedyk wrote:
> There is little reason not to use duplicate metadata. Only small
> files (less than 2kb) get stored in the tree, so there should be no
> worries about images being duplicated without data duplication set at
> mkfs time.

My benchmarks show that for my kinds of data, btrfs is somewhat slower
than ext4, (which is slightly slower than ext3 which is somewhat slower
than ext2), when using the defaults, (ie, duplicate metadata).

It's a hair faster than ext2, (the fastest of the ext family), when
using singleton metadata. And ext2 isn't even crash resistant while
btrfs has snapshots.

I'm using hardware raid for striping speed. (Tried btrfs striping, it
was close, but not as fast on my hardware). I want speed, speed, speed.
My data is only vaguely important, (continuous builders), but speed is
everything.

While the reason to use singleton metadata may be "little", it dominates
my application. If I were forced to use duplicate metadata then I'd
still be arguing with my coworkers about whether the speed costs were
worth it to buy snapshot functionality. But the fact that btrfs is
faster AND provides snapshots, (and less metadata overhead and bigger
file systems and etc), makes for an easy sale.

Note that nilfs2 has similar performance, but somewhat different
snapshot characteristics that aren't as useful in my current application.

--rich


\
 
 \ /
  Last update: 2010-09-01 00:03    [W:0.070 / U:0.764 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site