[dur-randir]

I have a 100TB array setup with LVM. I've thought (twice, each time I expanded this array) about using ZFS. It was ruled out for three things:

- there had been no raidz expansion (but now is, so this point is crossed)

- ZFS degrades read latency with the number of drives in array, while mdraid/lvm scales linearly - this is the price you pay for your checksums

- write-cache options on ZFS are atrotious, ZIL/SLOG are nothing compared to dm_writecache - I can stream 2GB/s full of sync writes until my cache drive is filled up, and it also provides reads to freshly written data, without going to backing pool

So, saying "why not ZFS" or "go buy some SSDs" is not really productive for promoting ZFS - it just underscores that "for ZFS" crowd are zealots.

[dangus]

My main point is that the article is applying artificial constraints as a reason to avoid using a gold-standard plug-and-play solution.

Basically, I’m saying that if you need this quantity of storage and storage performance, you’re best off not artificially constraining yourself to running on your existing box or using a non-NAS oriented Linux distribution. You’ll have a much easier time going with a single-purpose storage solution like TrueNAS where it’s running a dedicated OS on dedicated hardware.

It doesn’t really have to be ZFS-based, either, but most people in the homelab community seem to agree that TrueNAS is a top option.

I would say that suggesting a web GUI solution versus a bespoke thing like we see in the article isn’t exactly a “zealot”-like thing to do.

[ggm]

Maybe I skimmed too fast, but I didn't see your criticisms in the write up cited. They're a good critique, ssd aside: ssd are magic, any filesystem.

ZFS mainline kernel aside, is the only FS I've seen which is able to encompass redundancy and is portable BSD <-> Linux. It isn't a big reason I run it, but it's one of them. Snapshotting is the big reason although the various journal fs had this ages ago.

I don't personally feel a zealot, but I admit to proselytising.