OSNews > Thread > "RE[2]: Only so few?" by kwag

Linked by Rahul on Fri 31st Oct 2008 16:12 UTC

InternetNews talks to developers and vendors about the rise of Btrfs as a successor to Ext4. Though Ext4 adds extents, Chris Mason, Btrfs developer noted that BTRFS adds a number of other features beyond that. Among those features are items like snapshotting, online file consistency checks and the ability to perform fast incremental backups. BTRFS (pronounced better FS) is currently under development in an effort led by Oracle engineer Chris Mason. With the support of Intel, Red Hat, HP, IBM, BTRFS could become the engine that brings next generation filesystem capabilities to Linux.

2 29 Comment(s)

http://osne.ws/fsm

Thread beginning with comment 335890
To view parent comment, click here.
To read all comments associated with this story, please click here.

RE[2]: Only so few?

by kwag on Fri 31st Oct 2008 20:18 UTC in reply to "RE: Only so few?"

Member since:
2006-08-31

Even when it reaches v1.0, BTRFS will be far behind ZFS.
Just look at the features.
Also there are no current plans for transparent compression on BTRFS, and I consider that a must for many cases.
Not to mention the ZFS syntax is so dead plain simple.
Not so for BTRFS.
I run ZFS on Linux (for a long time now!) via FUSE, and I'm very happy with it

Edited 2008-10-31 20:19 UTC

Reply Parent Bookmark Score: 4

RE[3]: Only so few?

by poundsmack on Fri 31st Oct 2008 20:48 in reply to "RE[2]: Only so few?"

Member since:
2005-07-13

oh i never said it was going ot be as good as ZFS (as i love ZFS with a pasion) only that it will be nice to have some ceompetion to ZFS and NTFS (yes NTFS is a very good file system, i don't care that its an MS product, its till good).

Reply Parent Bookmark Score: 6

RE[3]: Only so few?

by diegocg on Fri 31st Oct 2008 21:56 in reply to "RE[2]: Only so few?"

Member since:
2005-07-08

Even when it reaches v1.0, BTRFS will be far behind ZFS. Just look at the features.

Sure it won't implement all the "advanced" features, but it will implement all the features people cares about - mutiple device management, raid-z, selfhealing, cheap snapshots. And other features (like I/O priority) don't even need to be implemented by btrfs because they are already implemented in the generic block layer.

Also there are no current plans for transparent compression on BTRFS

Transparent compression on btrfs was merged two days ago - http://git.kernel.org/?p=linux/kernel/git/mason/btrfs-unstable-stan...

Edited 2008-10-31 21:57 UTC

Reply Parent Bookmark Score: 6

RE[4]: Only so few?

by kwag on Sat 1st Nov 2008 02:31 in reply to "RE[3]: Only so few?"

Member since:
2006-08-31

"Transparent compression on btrfs was merged two days ago - http://git.kernel.org/?p=linux/kernel/git/mason/btrfs-unstable-stan...

Thanks for that info!
I didn't see that because I'm syncing to the stable branch.

Reply Parent Bookmark Score: 1

RE[4]: Only so few?

by Weeman on Sat 1st Nov 2008 13:29 in reply to "RE[3]: Only so few?"

Member since:
2006-03-20

And other features (like I/O priority) don't even need to be implemented by btrfs because they are already implemented in the generic block layer.

IO priority would still be better implemented in the filesystem itself if you value performance. That way, the scheduler can do its work better since it's aware about the state of the filesystem and its structures, can reorder things better than a generic layer unaware of anything and just getting a list of requests.

Reply Parent Bookmark Score: 2

RE[3]: Only so few?

by zdzichu on Sat 1st Nov 2008 14:35 in reply to "RE[2]: Only so few?"

Member since:
2006-11-07

Also there are no current plans for transparent compression on BTRFS, and I consider that a must for many cases.

You are behind the times.

http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg00887.ht...

Reply Parent Bookmark Score: 1