Hacker News Reader

Comment by dangus | Hacker News Reader

Yeah I really didn’t understand why ZFS or something like a TrueNAS dedicated storage solution setup was ruled out so quickly.

But before we even go there, we have to consider an all-SSD solution. SSDs are so cheap nowadays. It’s a trivial cost to buy a 2-4TB SSD. Heck, even an 8TB SSD is reasonably affordable, only about $600.

So first step is justifying a complicated caching setup. Why cache at all when you can just use all SSD storage and bring the complexity down a whole lot?

And if you’re using more than 2-8TB of storage and you’re in the spinning disk territory, why are you not using a dedicated NAS solution like TrueNAS?

This solution just seems like one of the worst possible choices.

View on HN

Buying 3-4 $600 ssds instead of HDDs that cost about quarter of that is quite a bit difference.

Though I feel like it's cheaper and sufficient for most home use nas to buy some cheap phased out ddr4 to get let's say 128gb and let it cache things there, and the ram can be handy for other uses

Disks are noisy. My FS lives in a room I need to be quiet. Disks are hot. I had hoped SSD would run cooler, they are hot but I find the room is perhaps a bit cooler now too.

Disks however, are much, much, much cheaper. Your ramcache point is well made.

The real point isn’t about the literal cost savings with spinning drives, the point is that if you’re at a capacity level where the cost is becoming a factor that represents more than one evening out at your favorite restaurant, you’re at the point where a dedicated NAS solution is going to make sense for you.

And once you are at that point there is no sense in fussing around with setting up a “bespoke” solution like this that is a product of artificial constraints.

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.

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.

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.

Reply on news.ycombinator.com