From your link: Btrfs, when complete, is expected to offer a feature set comparable to Sun's ZFS.
It's as silly as the politicians in my country. About three or four years ago, they paid an absurd sum of money for a super computer that would be the third of the world when complete. Big surprise: three years later, once completed, the machine does not make it even into the list of the top 100.
> In my opinion, the basic architecture of btrfs is more
> suitable to storage than that of ZFS. One of the major
> problems with the ZFS approach - "slabs" of blocks of a
> particular size - is fragmentation. Each object can contain
> blocks of only one size, and each slab can only contain
> blocks of one size. You can easily end up with, for example,
> a file of 64K blocks that needs to grow one more block, but
> no 64K blocks are available, even if the file system is full
> off nearly empty slabs of 512 byte blocks, 4K blocks, 128K
> blocks, etc. To solve this problem, we (the ZFS developers)
> invented ways to create big blocks out of little blocks
> ("gang blocks") and other unpleasant workarounds. In our
> defense, at the time btrees and extents seemed fundamentally
> incompatible with copy-on-write, and the virtual memory
> metaphor served us well in many other respects.
Describing btrfs and zfs as 'exactly the same' just because most of the features that are talking about or that you care about are the same isn't the whole truth. [Not directed at you, but most discussions seem to assume some sort of equivalency between the two filesystems.]
From your link: Btrfs, when complete, is expected to offer a feature set comparable to Sun's ZFS.
It's as silly as the politicians in my country. About three or four years ago, they paid an absurd sum of money for a super computer that would be the third of the world when complete. Big surprise: three years later, once completed, the machine does not make it even into the list of the top 100.
Also, dupe.