Linked by Thom Holwerda on Mon 12th Jan 2009 21:35 UTC, submitted by diegocg
Thread beginning with comment 343285
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.
from the btrfs wiki (http://btrfs.wiki.kernel.org):
The main Btrfs features include:
* Extent based file storage (2^64 max file size)
* Space efficient packing of small files
* Space efficient indexed directories
* Dynamic inode allocation
* Writable snapshots
* Subvolumes (separate internal filesystem roots)
* Object level mirroring and striping
* Checksums on data and metadata (multiple algorithms available)
* Compression
* Integrated multiple device support, with several raid algorithms
* Online filesystem check
* Very fast offline filesystem check
* Efficient incremental backup and FS mirroring
* Online filesystem defragmentation
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.







Member since:
2008-10-23
In my opinion, Btrfs will be no match for 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. 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.