Hacker News Reader

Comment by bsder | Hacker News Reader

> 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).

View on HN

vdev removal is in the canonical source of illumos at this point: http://blog.delphix.com/alex/2015/01/15/openzfs-device-remov...

Thanks. This has been on the timeline for several years now. Nice to see that it finally hit.

IIRC, there were some other nice things that this enabled as well.

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.

Um, yeaaaah. Focused on enterprise. Which one do you think is more important to enterprise customers? Not being able to shrink or not having RAID.

It only had limited raid5/6 support. With embedded checksums and mirroring available that's not a terrible situation to be honest.

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.

Reply on news.ycombinator.com