1. Author dislikes ZFS because you can't grow and shrink a pool however you want.
2. Author likes BTRFS because it implements more flexible grow/shrink, but finds that in other ways it's unstable, and is unhappy that BTRFS doesn't let you have arbitrary numbers of parity drives.
> 1. Author dislikes ZFS because you can't grow and shrink a pool however you want.
I believe that this was on the future timeline for ZFS. It required something like the ability to rewrite metadata or something.
The problem is that nobody really cares about this outside of a very few individual users. Anybody enterprise just buys more disks or systems. Anybody actually living in the cloud has to deal with entire systems/disks/etc. falling over so ZFS isn't sufficiently distributed/fault tolerant.
So, you have to be an individual user, using ZFS, in a multiple drive configuration to care. That's a really narrow subset of people, and the developers probably give that feature the time they think it deserves (ie. none).
ZFS device removal is on its way but not quite in illumos yet. From Alex's blog post: "We’ll publish the code when we ship our next release, probably in March [2015], [and we will] integrate into Illumos once we address all the future work issues."
Isn't it funny then that BTRFS supports growing and shrinking? Sounds like it's not such an edge case at all. BTRFS is also focussed on the enterprise, yet it is implemented.
People have been working around the limitations of lvm and Linux raid for years... it's not such a big deal. The issue with BTRFS is the stability and consistent performance, especially when the disk gets close to being full.
Would definitely prefer BTRFS to be stable over having additional features...
If you include that "using ZFS", it is a small subset and "a few individual users", but that may be because they care and don't choose ZFS because of it.
If you remove that clause, I would think there are way more people in that situation. That still wouldn't imply that those who write ZFS have to care, though. There's nothing wrong with providing a great solution for a selected subset that isn't suitable for the majority. In ZFS's case, that certainly applies. For its target audience, the ability to shrink pools is nice to have, and nowhere to minimum viable product.
That argument applies to btrfs, too, by he way.cthere are way more users for whom something like Google drive is a better option than running their own btrfs system.cthat doesn't mean there is no reason to develop btrfs.
The author wants zfs to support growing and shrinking pools in a specific way that it doesn't support.
However it's clear from the docs that you can grow zfs pools by adding new vdevs. Shrinking a pool is not possible.
In practice I haven't seen the inability to shrink pools as an issue. I simply do not create pools from entire disks and use partitions instead. For example each drive is split into 5 partitions. And if I need to grow a pool I add another partition across all my disks to the pool as a new vdev.
This also allows me to have multiple pools on each system that have different Raid-z levels based on different app reqs.
It is clear from the article that I acknowledge this fact but it is a more convoluted, less flexible solution that wastes space. BTRFS shows how it can and should be done.
Shrinking the filesystem is something I have never needed to do since becoming interested in computers in 1992. The only times I have really read about it is when people want to make room for a second OS.
I've seen people shrink filesystems to clone whiteboxes, and I can see some use cases in the embedded world, though these probably aren't the places you want to use zfs or btrfs.
Correct TLDR. But with BTRFS it's not about 6 parity drives. It's about not support tripple-parity or even RAID60. Features supported by ZFS since eons.
1. Author dislikes ZFS because you can't grow and shrink a pool however you want.
2. Author likes BTRFS because it implements more flexible grow/shrink, but finds that in other ways it's unstable, and is unhappy that BTRFS doesn't let you have arbitrary numbers of parity drives.