Linked by Thom Holwerda on Mon 12th Jan 2009 21:35 UTC, submitted by diegocg
Linux Versin 0.17 of the Linux filesystem btrfs has been released. The main news on this release is that it has been included in the Linus' tree. The changes include support of transparent compression, seed devices, improved block sharing while moving extents, improved block allocation and many bug fixes and performance improvements. Also, the disk format is not expected to change unless a critical bug is found.
Thread beginning with comment 343315
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: BTRFS vs ZFS
by Mark Williamson on Tue 13th Jan 2009 19:36 UTC in reply to "RE: BTRFS vs ZFS"
Mark Williamson
Member since:
2005-07-06

In my opinion, Btrfs will be no match for ZFS.


Probably true for now, since Btrfs is very new and still in development. You certainly wouldn't want to replace a ZFS deployment with Btrfs!

However, the idea seems to be that it will support basically all the things that ZFS does. It is built on a conceptually very similar basis to ZFS and already supports a large number of the headlining attractive features of ZFS.

ZFS has removed the unnecessary layering, which helped to simplyfy the code and resulted in fewer lines of code and better integration between the "layers". Btrfs will be just filesystem, whereas ZFS is a volume manager and RAID too.


Btrfs has the ability to be spread over multiple devices like ZFS - this is supported natively in the filesystem (the filesystem including aspects of LVM- and RAID-type functionality) as it is with ZFS. I don't think it supports the complex self-healing or advanced RAID modes (RAID-Z) that ZFS does *yet* but the model allows for it and I imagine they'll emerge in future.


This allows for very nice features, like self healing in situation, when only one side of mirror gets corrupt (in case of hw failure for example). Since Btrfs will use existing RAID implementation (AFAIK) it won't be able to do that. But this is just one example which comes to my mind ATM.


I think Btrfs will be aiming to do this - its design facilitates it.

Interestingly the main Tux 3 developer is taking the attitude that his filesystem should support at least some Btrfs / ZFS features (e.g. subvolumes) by modifying the FS<->LVM/RAID interface to better to support them, rather than by implementing them entirely in the filesystem. Since this could potentially result in more flexible code and more code reuse, I'll be very interested to see if this gets done.

Reply Parent Bookmark Score: 3