Btrfs has gotten _much_ faster

Ranguvar · 2009-09-03 05:57:42

As I remember from old benchmarks (a few months ago), Btrfs was HORRIBLE in terms of performance, and although the devs had said that was what they wanted to tackle next, optimization, I was worried we'd end up with a featureful, but slow, filesystem.

Well, optimize they did. http://www.linux-mag.com/cache/7497/1.html (The benchmark stresses metadata performance, but I still think it's a good one)

Woot for the Linux ZFS!

.:B:. · 2009-09-03 07:50:13

<3

Is it stable enough to use as a day-to-day file system? I guess not, given how long it took for Ext4 to get to a stable state...

moljac024 · 2009-09-03 08:54:55

Reinstalling to change a file system just sucks....I reinstalled Arch only once (not counting a few reinstalls in the first week of usage) to encrypt all partitions with LUKS and it was a drag having to configure everyting again (even with backups)

/rant

bangkok_manouel · 2009-09-03 09:02:18

B wrote:

<3
Is it stable enough to use as a day-to-day file system? I guess not, given how long it took for Ext4 to get to a stable state...

maybe not yet http://www.mail-archive.com/linux-btrfs … 02500.html
also, nice article about btrfs http://lwn.net/Articles/342892/

Zariel · 2009-09-03 10:54:11

Im going to hold off reinstalling again (i can do a turn around in hours with my backups i686->x64->i686->x64 in 2 months is fun) to an encrypted base system to wait to see what happens with filesystems in the kernel, if btrfs aproaches usability then ill use that, or if reiser4 enters mainline ill use that.

Fun times ahead!

andre.ramaciotti · 2009-09-03 13:57:55

IIRC, it is (will be) possible to mount a ext4 filesystem as btrfs, so there'll be no need for reinstalling.

Ranguvar · 2009-09-03 14:33:18

B wrote:

Is it stable enough to use as a day-to-day file system? I guess not, given how long it took for Ext4 to get to a stable state...

Ask Linus
That isn't a technical problem with Btrfs really, but it was funny. No, I wouldn't say it's stable.

Last edited by Ranguvar (2009-09-03 14:33:58)

broch · 2009-09-03 14:44:56

looks like zfs wannabie. Oracle got sun, zfs can be free, but probably is nothing more than btrfs is a poor man's zfs.

What bothers me is politics, in past SD scheduler was killed because of politics and we have been given CFQ which is utter crap, is this going to happen with zfs/btrfs also?

I hope not, but I am rather pesimistic

bangkok_manouel · 2009-09-03 14:51:51

broch wrote:

looks like zfs wannabie. Oracle got sun, zfs can be free, but probably is nothing more than btrfs is a poor man's zfs.
What bothers me is politics, in past SD scheduler was killed because of politics and we have been given CFQ which is utter crap, is this going to happen with zfs/btrfs also?
I hope not, but I am rather pesimistic

btrfs being in the kernel (unlike SD sched), it is very unlikely that it'll get killed. a lot of people are waiting for it too.

Zariel · 2009-09-03 14:56:32

broch wrote:

looks like zfs wannabie. Oracle got sun, zfs can be free, but probably is nothing more than btrfs is a poor man's zfs.
What bothers me is politics, in past SD scheduler was killed because of politics and we have been given CFQ which is utter crap, is this going to happen with zfs/btrfs also?
I hope not, but I am rather pesimistic

Did you read this ? http://lwn.net/Articles/342892/

Written by an ex ZFS developer and is very interesting.

In my opinion, the basic architecture of btrfs is more suitable to storage than that of ZFS. One of the major problems with the ZFS approach - "slabs" of blocks of a particular size - is fragmentation. Each object can contain blocks of only one size, and each slab can only contain blocks of one size. You can easily end up with, for example, a file of 64K blocks that needs to grow one more block, but no 64K blocks are available, even if the file system is full off nearly empty slabs of 512 byte blocks, 4K blocks, 128K blocks, etc. To solve this problem, we (the ZFS developers) invented ways to create big blocks out of little blocks ("gang blocks") and other unpleasant workarounds. In our defense, at the time btrees and extents seemed fundamentally incompatible with copy-on-write, and the virtual memory metaphor served us well in many other respects.

broch · 2009-09-03 15:45:48

btrfs being in the kernel (unlike SD sched), it is very unlikely that it'll get killed. a lot of people are waiting for it too.

hmm. cfq was not even on the paper, still Kolivas project was ignored. This was politics.

@Zariel
I red the article, that is from someone who is working on btrfs now. The advantage of zfs is that it is older (tested), there are aplications for zfs and new will come in.
In two yrs btrfs may have exactly the same problems as ext4, this is inevitable, so if btrfs will be in two years in the main tree or not, you will need to wait next few years to mature while zfs is full fledged, tested fs.
On the paper everything may look better.

zodmaner · 2009-09-03 16:36:32

Hope that btrfs will be more reliable than ext4 (and ext3 too, hopefully) when it finished.

Last edited by zodmaner (2009-09-03 16:38:33)

Ranguvar · 2009-09-03 18:31:23

Hmm? ext4 is rock-solid for me, and ext3 with data=ordered (the old standard, new is writeback) is the gold standard. Absolutely perfect. The only problems with ext4 were due to apps expecting ext3-style 5-second-writes rather than following POSIX, and there are patches to 2.6.30 to hopefully resolve all those problems. I used ext4 since the first kernel it was introduced in, and until 2.6.30 I use nodelalloc to force ext3-style behavior (still faster, just not as fast).

But not to turn this into another ext4 thread, I don't think Btrfs has anything that would make it more or less stable than extX.

oli · 2009-09-04 07:30:30

Ranguvar wrote:

As I remember from old benchmarks (a few months ago), Btrfs was HORRIBLE in terms of performance, and although the devs had said that was what they wanted to tackle next, optimization, I was worried we'd end up with a featureful, but slow, filesystem.
Well, optimize they did. http://www.linux-mag.com/cache/7497/1.html (The benchmark stresses metadata performance, but I still think it's a good one)
Woot for the Linux ZFS!

First I need stability than performance. W00t for a _rock-stable_ filesystem.

oli · 2009-09-04 07:34:40

zodmaner wrote:

Hope that btrfs will be more reliable than ext4 (and ext3 too, hopefully) when it finished.

The problem is, to make a filesystem really stable it takes years! Ext4 is quiet stable, but I wouldn't count on it in every situation. And I will use brtfs if some major datacenters are using it :-) At them moment I'm more fond of jfs and xfs and I'm not talking of a desktop.

Misfit138 · 2009-09-04 13:45:23

oli wrote:

zodmaner wrote:
Hope that btrfs will be more reliable than ext4 (and ext3 too, hopefully) when it finished.
The problem is, to make a filesystem really stable it takes years! Ext4 is quiet stable, but I wouldn't count on it in every situation. And I will use brtfs if some major datacenters are using it :-) At them moment I'm more fond of jfs and xfs and I'm not talking of a desktop.

I can't help but love JFS..stable, proven and good performance..the only things it is missing are online defragmentation ability and filesystem shrinkage.
BTRFS looks interesting.

oli · 2009-09-04 13:54:47

Yeah of course it looks interesting, it has got many nice features but in the end it's all about stability.

Arch Linux

#1 2009-09-03 05:57:42

Btrfs has gotten _much_ faster

#2 2009-09-03 07:50:13

Re: Btrfs has gotten _much_ faster

#3 2009-09-03 08:54:55

Re: Btrfs has gotten _much_ faster

#4 2009-09-03 09:02:18

Re: Btrfs has gotten _much_ faster

#5 2009-09-03 10:54:11

Re: Btrfs has gotten _much_ faster

#6 2009-09-03 13:57:55

Re: Btrfs has gotten _much_ faster

#7 2009-09-03 14:33:18

Re: Btrfs has gotten _much_ faster

#8 2009-09-03 14:44:56

Re: Btrfs has gotten _much_ faster

#9 2009-09-03 14:51:51

Re: Btrfs has gotten _much_ faster

#10 2009-09-03 14:56:32

Re: Btrfs has gotten _much_ faster

#11 2009-09-03 15:45:48

Re: Btrfs has gotten _much_ faster

#12 2009-09-03 16:36:32

Re: Btrfs has gotten _much_ faster

#13 2009-09-03 18:31:23

Re: Btrfs has gotten _much_ faster

#14 2009-09-04 07:30:30

Re: Btrfs has gotten _much_ faster

#15 2009-09-04 07:34:40

Re: Btrfs has gotten _much_ faster

#16 2009-09-04 13:45:23

Re: Btrfs has gotten _much_ faster

#17 2009-09-04 13:54:47

Re: Btrfs has gotten _much_ faster

Board footer