Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

DIY NAS: 2026 Edition

blog.briancmoses.com

Post reply on HN
Print view View original

281–290 of 315 posts

Re: DIY NAS: 2026 Edition

#281

Post by 8fingerlouie »

Havoc wrote: post #256
8fingerlouie wrote: post #235

Holy smokes, the NAS in idle consumes more power than my UNAS Pro with 4x8TB HDD and 2X8TB SSD, as well as a Mac mini M1 with a 2TB Samsung T7 SSD, and my 4 access points and 4 protect cameras combined. For reference, the UNAS Pro comes with 10G networking, and will deliver roughly 500MB/s from a 4 HDD RAID5 array, and close to 1GB/s from the SSDs (which it never gets a chance to do, as I use them for photos/document…

Once you venture outside of shove files down network pipe territory you'll find you're comparing apples and oranges. About 10x difference in CPU performance, 4x in RAM, zfs vs btrfs, quicksync, kubernetes/docker etc. Doesn't make the unify an inferior machine - it just reflects a narrower specialized focus on serving files...and yes does so with lower idle draw.

did you forget the Mac Mini M1 in that comparison ?

My setup, UNAS and Mac Mini M1, with 10Gbps networking, will easily perform as well as the NAS in question, but the Mac Mini only uses 4.6W idle, making it much more efficient.

As for ZFS vs Btrfs, they're about equal unless you're doing some very specific things. For most normal server stuff or NAS stuff, Btrfs is every bit as competent as ZFS. Snapshots, compression, RAID1+, recovery, bitrot detection, they're pretty much equal. ZFS as an advantage with RAIDZ1/2 as Btrfs apparently hasn't managed to make RAID5/6 stable in the past decade. You can however run RAID1 across multiple devices with multiple copies, which is not quite the same, but also not terrible.

The RAM usage of ZFS is also largely a myth. Yes, it will use RAM if available, but that is mostly because it was designed with it's own file cache, which was probably fine on Solaris, and to some extent on FreeBSD, but Linux uses a shared block cache, and instead of files being cached in the shared cache, ZFS will cache them, making it look like it hogs RAM.

Re: DIY NAS: 2026 Edition

#282

Post by 8fingerlouie »

shadowpho wrote: post #251
8fingerlouie wrote: post #235

Holy smokes, the NAS in idle consumes more power than my UNAS Pro with 4x8TB HDD and 2X8TB SSD, as well as a Mac mini M1 with a 2TB Samsung T7 SSD, and my 4 access points and 4 protect cameras combined. For reference, the UNAS Pro comes with 10G networking, and will deliver roughly 500MB/s from a 4 HDD RAID5 array, and close to 1GB/s from the SSDs (which it never gets a chance to do, as I use them for photos/document…

> the NAS in idle consumes more power than my UNAS Pro with 4x8TB HDD and 2X8TB SSD, as well as a Mac mini M1 with a 2TB Samsung T7 SSD, and my 4 access points and 4 protect cameras combined. Are your drives spun? 70w is a pretty low bar. The nas by itself is probably 40w with drives, Mac mini is another 7-10w (especially at wall) and now we are at 50w, so 20w left for 4 AP and cameras

drives are spinning. 4x8TB WD Red Plus, which uses 3.4W idle, and assuming 20W for the NAS it's at ~34W (measured 35W). Mac Mini uses 4.6W idle (headless). POE consumption (measured by switch) is 37W (I'm aware there's overhead in AC/DC conversion).

All in all the total consumption at the wall is 96W, but as i have written in another comment, i was 7-8W off, meaning the quoted setup of mine uses 7-8W more than the 66.7W OPs NAS idles at.

Re: DIY NAS: 2026 Edition

#283

Post by Helmut10001 »

Glemkloksdjf wrote: post #279
Helmut10001 wrote: post #183

Earlier quoted context omitted.

The protocol is better (SAS). Once I put them in, I immediately noticed transmission issues in a counter going up for several of my HDDs where the SATA showed no errors at all. It was a faulty backplane that introduced these transmission issues that went unnoticed by my SATA drives for several years.

Could you elaborate? Did your HDDs then wrote broken data? Do you use ZFS? I think that should have indicated some HDD issues independent of a counter by transferspeed or something like this. Not that the backplane was just not good in handling SAS?

Yes, I am using ZFS (Raidz2), which is exactly why I know the data remained intact despite the transmission errors. Here is the breakdown of what happened during my recent migration 5 weeks ago and why the SAS protocol made the difference:

> Did the HDDs write broken data?

No. ZFS handles end-to-end data integrity via checksums. If the data had been corrupted during the transfer, ZFS would have flagged it as CKSUM errors in zpool status. Because ZFS validates the data after it crosses the wire, I could be confident that the data written to disk was valid, or the write would have been rejected/retried. However, ZFS did not notice any errors because the SATA/SAS firmware error correction were (still) able to handle this through repeated submission of signals.

> SAS vs. SATA

The issue was that my old backplane (BPN-SAS-743TQ) was electrically failing (signal degradation), but not dead yet. For years, my SATA drives likely engaged in silent retries or masked these marginal signal issues. I know I had issues for years, where I suspected bad cables (this had cost me $500 to replace several cables to try solving this). Standard SATA SMART attributes often only flag UDMA_CRC_Error_Count if things get very bad, but they are generally less verbose about link stability to the HBA. As soon as I plugged in the SAS drives, the mpt3sas driver and the drives themselves flooded dmesg and SMART logs with Invalid DWORD count errors. SAS has robust Physical Layer (PHY) error reporting. It wasn't waiting for data corruption. It was alerting me that the signal integrity on the way between the HBA and the drive was compromised.

> Was the backplane just incompatible?

No, it was physically faulty. I performed a standard isolation test:

    - I took a "suspect" SAS drive and moved it to a known-good bay -> No errors.
    - I took a known-good SAS drive and put it in the "suspect" bay -> Immediate errors.
I did the same with the cables. During both tests (drives & cables), the errors stayed with the specific bays on the backplane. This proved the backplane was introducing signal noise on some bays. The SAS drives screamed about this noise immediately, whereas the SATA drives had been tolerating (and hiding) it.

To sum up, ZFS kept the data safe (logical layer), but switching to SAS enterprise drives exposed a rotting hardware component (physical layer) that consumer SATA drives were ignoring. If I had been using a hardware RAID card with SATA, I likely wouldn't have known until a drive dropped offline entirely.

I later read that backplanes do degrade regularly due to temperature stress etc. I put in a replacement backplane and all was solved.

Re: DIY NAS: 2026 Edition

#284

Post by ffsm8 »

SJetKaran wrote: post #277
zeroq wrote: post #258

I wanted to join the NAS club for so long but it was always either bang for buck for prebuilts ($1k for 4 bays, with 4Gb RAM and the CPU is slower than my previous phone?!) or lack of availability for 4+ SATA boards. Last year I had aha moment when I learned about SAS boards. My final build was: - Jonsbo N3 case - ITX PSU - ASRock B550M/ITX - Ryzen 5500GT - LSI 9207-8i - 16GB DDR4 Result - for ~$1k I have 8 bay NAS t…

What is Ryzen adding here towards the NAS part of this system? Or is it only for gaming?

NAS in this context is more about home server then an actual plain network attached storage.

I usually call mine NAS too, despite technically using it more for selfhosting - and basically never mounting it's data volumes. I think this applies to almost everyone using them nowadays, which is also the reason why the pre built ones are less and less relevant - because they always have super conservative CPUs (which are more then sufficient for a NAS that's actually used as a plain network attached storage - but severely underperforming if the user wants to run services on it.)

Re: DIY NAS: 2026 Edition

#285

Post by npodbielski »

Looks nice but now when I have server with IPMI and BMC chip I won't go back. Taking monitor and GPU to the basement when there is boot error or you need change BIOS settings is no fun. Remote management is very helpful this way. And with tailscale you can I.e. reboot your server remotely, even if SSH does not connect.

Re: DIY NAS: 2026 Edition

#286

Post by Havoc »

8fingerlouie wrote: post #281
Havoc wrote: post #256

Earlier quoted context omitted.

Once you venture outside of shove files down network pipe territory you'll find you're comparing apples and oranges. About 10x difference in CPU performance, 4x in RAM, zfs vs btrfs, quicksync, kubernetes/docker etc. Doesn't make the unify an inferior machine - it just reflects a narrower specialized focus on serving files...and yes does so with lower idle draw.

did you forget the Mac Mini M1 in that comparison ? My setup, UNAS and Mac Mini M1, with 10Gbps networking, will easily perform as well as the NAS in question, but the Mac Mini only uses 4.6W idle, making it much more efficient. As for ZFS vs Btrfs, they're about equal unless you're doing some very specific things. For most normal server stuff or NAS stuff, Btrfs is every bit as competent as ZFS. Snapshots, compressi…

I genuinely don't even know what to do with this comment. You're upset that I contrasted two NAS instead you wanted a NAS vs NAS+Other stuff?

I regret commenting at all...

Re: DIY NAS: 2026 Edition

#287

Post by AlanYx »

ihaveone wrote: post #245
AlanYx wrote: post #220

Earlier quoted context omitted.

This is what I recommend too, but for those who want something prepackaged, there's also XigmaNAS, basically a lightweight UI layer and basic configuration on top of FreeBSD. Some of the original FreeNAS developers have been working on the project for almost 20 years. It's great for people who just want storage and don't want the heavy features that came with TrueNAS' move to Linux (Kubernetes, etc.) or who want full…

Are you sure it's not called LigmaNAS?

That might be a better name :) The project doesn't have as much visibility as it should because it's gone through several names over the last 20 years: FreeNAS (prior to the TrueNAS split), NAS4free, and now XigmaNAS.

Re: DIY NAS: 2026 Edition

#288

Post by else42 »

ls612 wrote: post #227
else42 wrote: post #225

Earlier quoted context omitted.

Wrong. I pay €0,23/kWh, so do your homework. What exactly is failing in Germany, and why is it important in this context?

They have failed to have a sensible industrial and energy policy, leading to around net 0 GDP growth since 2019. I’m sure for the degrowth elites though this is not a failure it is working as intended.

[dead]

Re: DIY NAS: 2026 Edition

#289

Post by machomaster »

Strom wrote: post #209
hamdingers wrote: post #190

Earlier quoted context omitted.

I don't understand why this is a problem for some people. It doesn't increase the price or impact your buyer experience in any way, so why do you care? If this blog post introduced you to a product you wanted to buy, why should you have a problem with the author getting a finders fee from the seller ? Just seems mean-spirited.

It impacts the buyer experience. These two statements have a very different impact: 1. I love product X and I won't get paid if you buy it too. 2. I love product X and I will get paid if you buy it too. Money motivates people to claim they love a product or that a product is good, even if not true. It's a problem that has plagued the internet for decades.

3. I love product, but don't have an incentive to spend my time and sharing my experience for nothing.

It's not like this is an AI slop with no valuable unique information with the sole point of SEOing into visitors clicking on links.

The guy made his research, chose the best (not the most expensive, in order to maximize price) components and shared direct links (thus also making it easier for readers, who don't have only names that they would have to google themselves).

I see no problem in that so much so that I wouldn't even require a separate "I use affiliate links" caveats. This is useless info akin to "this website displays ads in order to be alive".

Re: DIY NAS: 2026 Edition

#290

Post by machomaster »

nothrabannosir wrote: post #273
mvkel wrote: post #236

Earlier quoted context omitted.

I don't think it's this binary. Influence and power are far more intoxicating currencies than affiliate revenue. And if someone complained "you're just publishing this helpful thing to become more influential in [community]," well, at some point we need to acknowledge incentives drive all behavior in one way or another. Refusing the incentive doesn't make one per se virtuous.

This thread is missing an important detail: > undisclosed affiliate links. That's quite controversial, compared to disclosed affiliate links. IMO for good reason.

Why?

I understand the need to disclose sponsored content. Or if the manufacturer had veto-power or any say in the content.

I even understand that it is good to tell if the product was given for free or the trip was paid, even when they had no say in the content.

But I don't understand why anyone would need "I use affiliate links" caveats. This is useless info wasting space and reading time akin to "this website displays ads in order to stay alive". What does writing this (otherwise observable facts) actually accomplishes? What benefits does it bring?

Post reply on HN