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

151–160 of 315 posts

Re: DIY NAS: 2026 Edition

#151

Post by AlanYx »

dwood_dev wrote: post #126
meindnoch wrote: post #81

Earlier quoted context omitted.

>I just made a 4 x 24 TB ZFS pool How much RAM did you install? Did you follow the 1GB per 1TB recommendation for ZFS? (i.e. 96GB of RAM)

That's only for ZFS deduplication which you should never enable unless you have very, very specific use cases. For normal use, 2GB of RAM for that setup would be fine. But more RAM is more readily available cache, so more is better. It is certainly not even close to a requirement. There is a lot of old, often repeated ZFS lore which has a kernel of truth but misleads people into thinking it's a requirement. ECC is be…

There are a couple recent developments in ZFS dedup that help to partially mitigate the memory issue: fast dedup and the ability to use a special vdev to hold the dedup table if it spills out of RAM.

But yes, there's almost no instance where home users should enable it. Even the traditional 5gb/1tb rule can fall over completely on systems with a lot of small files.

Re: DIY NAS: 2026 Edition

#152

Post by mvkel »

throwaway2037 wrote: post #102
p1necone wrote: post #39

Earlier quoted context omitted.

Looks like they built a new NAS, but kept using the same drives. Which given the number of drive bays in the NAS probably make up a large majority of the overall cost in something like this. Edit: reading comprehension fail - they bought drives earlier, at an unspecified price, but they weren't from the old NAS - I agree, when lifetimes of drives are measures in decades and huge amounts of tbw it seems pretty silly t…

This is the funniest edit have read in while.

Waiting for the edit to the edit

Re: DIY NAS: 2026 Edition

#153

Post by ceving »

antonkochubey wrote: post #66
mzhaase wrote: post #38

I would like to point people to the Odroid H4 series of boards. N97 or N355, 2*2.5GbE, 4*SATA, 2 W in idle. Also has extension boards to turn it into a router for example. The developer hardkernel also publishes all relevant info such as board schematics.

And the best feature is they have in-band ECC, which can correct one-bit and detect two-bit errors. No other Alder Lake-N or Twin Lake SBC exposes this feature in UEFI.

Can you give a reference for ECC? I can not find anything about ECC support on the Odroid site.

Re: DIY NAS: 2026 Edition

#154

Post by cm2187 »

jrrv wrote: post #140

What makes a motherboard a NAS motherboard, precisely? I've got a decent Mini-ITX sitting around and I've been contemplating setting up/getting a NAS. Would be nice if I could re-use what I already have and save some money.

Technically any motherboard can become a NAS, but there are desirable features.

- low idle power consumption since your NAS will be sitting doing nothing most of the time - pretty much any desktop MB will do

- fast networking, 1gbe means ~100MB/s transfers, nicer to have 10gbe. Limited benefits beyond 10gbe in practice.

- enough PCIe lanes to connect enough drives. HDD of course but nice to have a separate fast SSD array plus SSD caching. You might also want a SAS HBA if you are looking enterprise drives or SSDs (and even for SATA SSD you will get a better performance via a HBA than through the motherboard). Some people also want a graphic card for video transcoding

- ECC memory

- IPMI - once you start using it it becomes hard to give up. Allows you to manage the server remotely even when switched off, and access the BIOS via a web interface. Allows you to keep the server headless (i.e. not have to go plug a screen to understand why the server is taking so long to reboot).

I'd say a good candidate for a NAS motherboard would be something like a supermicro X11SSH-LN4F, you can find used ones pretty cheap on ebay.

Re: DIY NAS: 2026 Edition

#155

Post by briancmoses »

mvkel wrote: post #37

Wait. You build a new one every -year-?! How does one establish the reliability of the hardware (particularly the aliexpress motherboard), not to mention data retention, if its maximum life expectancy is 365 days?

Somebody else shared this, but I'm the blog's author. I think you're asking good questions, but they're not from the point-of-view of the people who actually benefit from these blogs.

I've answered the "You build one every year?" question quite a few times over the years.

These blogs have a shelf life. After about a year, newer hardware is available that's a better a better value. And after 2-3 years, it starts to get difficult to even find the many of the parts.

I don't replace my NAS every year, but every now and then I do keep my yearly NAS for my own purposes, but 2026 won't be one of those years.

> How does one establish the reliability of the hardware...?

One guy on the Internet is--and always will be--an anecdote, I could use this NAS until its hardware was obsolete and I'd still be unable to establish any kind of actual reliability for the hardware. Unfortunately, I don't have the time or money required to elevate beyond being a piece of anecdotal data.

However, there's a sizable audience out there who have realized that they need some kind of storage beyond what they already have, but haven't implemented a solution yet. I think if you put yourself in their shoes, you'll realize that anything is better than nothing in regards to their important data. My hope is that these blogs move that audience along towards finding that solution.

Re: DIY NAS: 2026 Edition

#156

Post by adrian_b »

antonkochubey wrote: post #66
mzhaase wrote: post #38

I would like to point people to the Odroid H4 series of boards. N97 or N355, 2*2.5GbE, 4*SATA, 2 W in idle. Also has extension boards to turn it into a router for example. The developer hardkernel also publishes all relevant info such as board schematics.

And the best feature is they have in-band ECC, which can correct one-bit and detect two-bit errors. No other Alder Lake-N or Twin Lake SBC exposes this feature in UEFI.

There is the ASUS NUC 13 Rugged, which also exposes the in-band ECC, but it is both much more expensive and much slower (it uses either a 2-core or a 4-core Atom CPU, while ODROID uses either a 4-core or an 8-core CPU of the same Gracemont-based series).

Re: DIY NAS: 2026 Edition

#157

Post by adrian_b »

ceving wrote: post #153
antonkochubey wrote: post #66

Earlier quoted context omitted.

And the best feature is they have in-band ECC, which can correct one-bit and detect two-bit errors. No other Alder Lake-N or Twin Lake SBC exposes this feature in UEFI.

Can you give a reference for ECC? I can not find anything about ECC support on the Odroid site.

The version using the 4-core CPU Intel N97, which is specified by Intel as an embedded CPU, certainly has in-band ECC, which was tested by some reviewers of this SBC.

I do not know whether the 8-core version (H4 Ultra) also enables in-band ECC, as for that CPU Intel does not specify embedded uses, so they may disable the ECC support in the factory.

See e.g.:

https://www.cnx-software.com/2024/05/26/odroid-h4-plus-revie...

However, looking right now at:

https://forum.odroid.com/viewtopic.php?f=171&t=48377

I see that someone has enabled successfully in-band ECC on the 8-core ODROID H4 Ultra and has run benchmarks with ECC disabled/enabled. Therefore it appears that in-band ECC support exists on all models.

The results of benchmarks with in-band ECC disabled/enabled may be not representative for real workloads. In-band ECC relies on caching the ECC bits in a dedicated ECC cache, in order to avoid excessive memory accesses. The effectiveness of the ECC cache can be very different for the benchmark and for the real workload, leading to misleading results. Usually for the real workload it is likely that the cache hit-rate will be higher, so the performance drop with in-band ECC enabled will be less conspicuous.

Re: DIY NAS: 2026 Edition

#158

Post by mindslight »

rubatuga wrote: post #14
WarOnPrivacy wrote: post #13

Earlier quoted context omitted.

> $10 / TB That's a remarkably good price. If I had $1.5k handy I'd be sorely tempted (even tho it's Seagate).

I've recently shucked some Seagate HAMR 26Tb drives hopefully they last

I won that lottery with 3x 26TB Exos shipped. I decided to try and get two more but they ended up being HAMR (returned). Then I managed to find two more earlier manufacturing dates in store stock at a somewhat-far Best Buy that I was driving past anyway.

It felt like an unnecessary purchase at the time (I'm still waiting to CAD a CPU cooler mounting solution for the build in a new case that has room for the drives). But it seems like that deal is going to be the high water mark for a few years, at least.

Re: DIY NAS: 2026 Edition

#159

Post by dwood_dev »

AlanYx wrote: post #151
dwood_dev wrote: post #126

Earlier quoted context omitted.

That's only for ZFS deduplication which you should never enable unless you have very, very specific use cases. For normal use, 2GB of RAM for that setup would be fine. But more RAM is more readily available cache, so more is better. It is certainly not even close to a requirement. There is a lot of old, often repeated ZFS lore which has a kernel of truth but misleads people into thinking it's a requirement. ECC is be…

There are a couple recent developments in ZFS dedup that help to partially mitigate the memory issue: fast dedup and the ability to use a special vdev to hold the dedup table if it spills out of RAM. But yes, there's almost no instance where home users should enable it. Even the traditional 5gb/1tb rule can fall over completely on systems with a lot of small files.

Nice. I was hoping a vdev for the dedup table would come along. I've wanted to use optane for the dedup table and see how it performs.

Re: DIY NAS: 2026 Edition

#160

Post by whynotmaybe »

cube00 wrote: post #90
SirFatty wrote: post #76

Earlier quoted context omitted.

How else is one to get the clicks?

Plus the commission from the undisclosed Amazon affiliate links in the post. They're tagged for the post and year so must be worth it to go to that trouble rather then using generic tag for the whole blog. tag=diyans2024-20, tag=diynas2025-20,tag=diynas2026-20

On a more rhetorical side, should they be disclosed?

Isn't that assumed nowadays that every link to a marketplace is an affiliate link?

Post reply on HN