Linked by Rahul on Fri 31st Oct 2008 16:12 UTC
Thread beginning with comment 335905
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
"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.
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.




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