OSNews

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.

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

Well, so much for "rampant layering violation" complains.

Indeed :-) I've actually been surprised, given those complaints about ZFS, that there hasn't been more (and vocal!) opposition to the Btrfs merge.

That said, maybe the kernel architecture of the two does differ somewhat. I had the impression that the ZFS architecture in Solaris included scope for other filesystems (e.g. UFS) to be implemented effectively as plugins to ZFS. Btrfs certainly doesn't seem to include anything like that, although I'm not entirely clear to what extent ZFS *does* vs *could*.

It is quite funny. When some in the Linux camp does some "layering violation" it is ok. But it is not ok that others, such as ZFS, does that.

What is that phenomena called? When you can do stuff, but when others does the same thing - it is a bad thing?

"Back in my day..."

Er, I mean: back in the usenet heyday, we used to call that "PKB" (short for Pot, Kettle, Black).

You can create raw volumes from you zpool and than create whatever filesystem on it, including (but not limited to) UFS. But why would you want to do that?

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.



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.



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.

Duh. Btrfs also removes the layering, it's not "just a filesystem"

Well what can you say? It's all their damn fault Althogh CDDL version of Linux would be cool.