3 ms·
There are far more than 2 people here: https://github.com/zfsonlinux/zfs/commits/master https://github.com/zfsonlinux/zfs/commits/master I will admit that my
by ryao 10y ago
There are far more than 2 people here:
https://github.com/zfsonlinux/zfs/commits/master https://github.com/zfsonlinux/zfs/commits/master
I will admit that my contribution activity has been low as of late, but it will pick up again soon. As for the bug list, that is because basically all distribution problems get sent there and duplicates are not closed until it is proven that they are duplicates. There is no such transparency with other filesystems' bug tracking. Redhat receives plenty of bug reports through Fedora that they happily close if not solved by EOL.
As for btrfs, one of the btrfs developers claimed that ZFS has 5 times the development resources of btrfs:
https://news.ycombinator.com/item?id=11749477 https://news.ycombinator.com/item?id=11749477
As for lawsuit fears, the fact is that using any software at all puts you at risk of a lawsuit. Whether or not the plaintiff has a legitimate case is a separate matter. However, if we consider the prospect of Oracle having a case against those using btrfs or ZFS, btrfs would be at higher risk. The CDDL provides an implicit patent grant while the GPLv2 does not. Any ZFS patents that are applicable to btrfs that Oracle accquired from Sun could be used against those using btrfs. The repercussions for Oracle would be huge, but if we are discussing about the potential for legal issues with Oracle, then btrfs is at the greatest risk.
From what I know of the internals of the two, btrfs has far more problems. This shows some of the problems on an enterprise distribution:
https://news.ycombinator.com/item?id=11749010 https://news.ycombinator.com/item?id=11749010
The idea that performance can be so horrible that the system might as well have deadlocked is a severe problem. The ENOSPC issues from internal fragmentation is another severe problem. Then there is the lack of backports. I could continue, but I see no need.