Linked by Rahul on Fri 31st Oct 2008 16:12 UTC
Linux 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.
Thread beginning with comment 335905
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: Only so few?
by diegocg on Fri 31st Oct 2008 21:56 UTC in reply to "RE[2]: Only so few?"
diegocg
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 Score: 6

RE[4]: Only so few?
by kwag on Sat 1st Nov 2008 02:31 in reply to "RE[3]: Only so few?"
kwag 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 Score: 1

RE[4]: Only so few?
by Weeman on Sat 1st Nov 2008 13:29 in reply to "RE[3]: Only so few?"
Weeman 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 Score: 2