Hacker News Reader

Comment by darkhelmet | Hacker News Reader

I've been using ZFS since circa 2008, but it's a tradeoff.

If I want no-worries and I don't want to be surprised by data loss, I use ZFS. If I want speed with data I can afford to lose, I use something else (ufs, ext4, xfs, the right FS for the job).

ZFS's integrity checking won't do a dang thing for you if you're not paying attention, don't have monitoring, or don't even run its checks. Yes, I over-provision. Yes, I'll make the reliability vs performance tradeoffs (when it makes sense, usually reliability over performance by default though).

The great thing about having options is exactly that. For me, ZFS is the right choice in most cases. For other people it's not. Being able to make an informed choice and not being forced either way is a good thing.

Zealotry/religion has no place in matters like this when there are clear tradeoffs in all the alternatives.

View on HN

I don't say it is the right choice in 'most cases', but its my preferred default choice for /etc and user home directories.

The hard case is databases. ZFS has a lot to offer (convenient support at FS level for replication stands out), but it is doing a lot of things that are solved problems in the design of competently designed databases and I never trust this kind of needless complexity. Of course if you really care about performance here, you should be willing to roll up your sleeves and tune the settings of the FS and ZFS is really nice in how it allows its complex features to be switched off.

> The hard case is databases.

I can kind of see your point, but I trust ZFS to never lose data, and I trust (in my case) postgres to never lose data, so the only issue is performance, and while that varies immensely, I mostly work on data that compresses well, so I can barely afford not to use ZFS with compression, because it saves a ton of space and actually improves I/O performance (if you're I/O bound, compressing your data lets you read and write faster than the physical disks can handle, which is still wild to me). Of course, that all depends on trusting all parts of the system; if I thought that ZFS+postgres could ever lose data, or possibly that there was a real risk of it causing an outage (say, memory exhaustion), it'd be a harder trade to make.

Losing data isn't the fear, it's that there might be weird corner cases that lead to badly unpredictable performance.

> I've been using ZFS since circa 2008, but it's a tradeoff.

Indeed. I was disappointed about the low quality of the article. A good article on why not ZFS would have been an interesting addition, to help users decide.

I've been using ZFS on my home NAS for over a decade and overall it's been a great experience, but as you say ZFS does have some limitations which makes it a poor fit for certain use-cases.

You say that you choose ZFS if you don't want to worry about data loss. My experience is the opposite of yours. The only time I experienced filesystem corruption (other than hardware failure) was when I upgraded to Ubuntu 21.10 on a ZFS installation. Ubuntu 21.10 released with a known bug in the ZFS implementation that caused filesystem corruption. I was disappointed to say the least.

That sounds like an Ubuntu problem more than a ZFS problem, no?

Very happy Ubuntu/ZFS user here, but we use only the LTS versions of Ubuntu.

Ubuntu didn't write the ZFS implementation.

If you release software with a known bug....

Ambiguous whether the bug was known at the time of release by Ubuntu. However, either way, it would have been released by ZFS authors first.

That's absolutely incorrect. The data-loss bug was created by Ubuntu developers when they developed a bad patch for a less-severe upstream OpenZFS issue.

The bug was introduced by Ubuntu in their own patch to ZFS code, which is why it only happened in very specific Ubuntu kernel package and nowhere else

Reply on news.ycombinator.com