Hacker News Reader

Comment by jeroenhd | Hacker News Reader

The (somewhat affordable) productized NASes all suffer from big tech diseases.

I think a lot of people underestimate how easy a "NAS" can be made if you take a standard PC, install some form of desktop Linux, and hit "share" on a folder. Something like TrueNAS or one of its forks may also be an option if you're into that kind of stuff.

If you want the fancy docker management web UI stuff with as little maintenance as possible, you may still be in the NAS market, but for a lot of people NAS just means "a big hard drive all of my devices can access". From what I can tell the best middle point between "what the box from the store offers" and "how do build one yourself" is a (paid-for) NAS OS like HexOS where analytics, tracking, and data sales are not used to cover for race-to-the-bottom pricing.

View on HN

The real trick, and the reason I don't build my own NAS, is standby power usage. How much wattage will a self built Linux box draw when it's not being used? It's not easy to figure out, and it's not easy to build a NAS optimized for this.

Whereas Synology or other NAS manufacturers can tell me these numbers exactly and people have reviewed the hardware and tested it.

To me, it's a question of time and money efficiency. (Time is money.)

I can buy a NAS, whereby I pay money to enjoy someone else's previous work of figuring it out. I pay for this over and over again as my needs change and/or upgrades happen.

I can build a NAS, whereby I spend time to figure it out myself. The gained knowledge that I retain in my notes and my tiny little pea brain gets to be used over and over again as needs change, and/or upgrades happen. And -- sometimes -- I even get paid to use this knowledge.

(I tend to choose the latter. YMMV.)

There are power meters like KWS-303L that will tell you how much manufacturers lie with their numbers.

For example my ancient tplink TL-WR842N router eats 15W standby or no, while my main box, fans, backlight, gpu, hdds and stuff -- about 80W idle.

Looking at Synology site the only power I see there is the psu rating, which is 90W for DS425. So you can expect real power consumption of about 30-40W. Which is typical for just about any NUC or a budget ATX motherboard with a low-tier AMD-something + a bunch of HDDs.

Actually I host everything on a linux PC/server, but a different box runs PFSense and a local DNS resolver so I was talking about setting up a split-brain DNS there. So I don't have to manually edit the hosts file on every machine and keep it up to date with IP changes. Personally I really like docker compose, its made running the little homeserver very easy.

Personally, I've started just using mDNS/Bonjour for local devices. Comes preinstalled on most devices (may need a manual package on BSD/Linux servers) and doesn't require any configuration. Just type in devicename.local and let the network do the rest. You can even broadcast additional device names for different services, so you don't need to do plex.nas.local, but can just announce plex.local and nas.local from the same machine.

There's a theoretical risk of MitM attacks for devices reachable over self-signed certificates, but if someone breaks into my (W)LAN, I'm going to assume I'm screwed anyway.

I've used split-horizon DNS for a couple of years but it kept breaking in annoying ways. My current setup (involving the pihole web UI because I was sick of maintaining BIND files) still breaks DNSSEC for my domain and I try to avoid it when I can.

I don't even understand what kind of webui one would want.

All you really need is a bunch of disk and an operating system with an ssh server. Even the likes of samba and nfs aren't even useful anymore.

A bunch of out-of-the-box NAS manufacturers provide a web-based OS-like shell with file managers, document editors, as well as an "app store" for containers and services.

I see the traditional "RAID with a SMB share" NAS devices less and less in stores.

If only storage target mode[1] had some form of authentication, it'd make setting up a barebones NAS an absolute breeze.

[1]: https://www.freedesktop.org/software/systemd/man/257/systemd...

Storage target mode is block-level, not filesystem-level, meaning it won't support concurrent access and any network hiccup or dropped connection will leave the filesystem in an unclean state.

> ...any network hiccup or dropped connection will leave the filesystem in an unclean state.

Given that the docs claim that this is an implementation of an official NVMe thing, I'd be very surprised if it had absolutely no facility for recovering from intermittent network failure. "The network is unreliable" [0] is axiom #1 for anyone who's building something that needs to go over a network.

If what you report is true, then is the suckage because of SystemD's poor implementation, or because the thing it's implementing is totally defective?

[0] Yes, datacenter (and even home) networks can be very reliable. They cannot be 100% reliable and -in my professional experience- are substantially less than 100% reliable. "Your disks get turbofucked if the network ever so much as burps" is unacceptable for something you expect people to actually use for real.

NVME only provides block IO. An interruption of the connection is equivalent to forcibly unplugging a hard drive. If the filesystem you put on top supports that and is able to recover from that, you're fine. But most filesystems do not optimize for that happening anywhere near as frequently as it would if you were using this as a regular file sharing protocol over unreliable networks.

> NVME only provides block IO.

Sure. NVMe provides block IO carried over a variety of transports. The one we're talking about is TCP.

> An interruption of the connection is equivalent to forcibly unplugging a hard drive.

Remember that I said in my footnote:

  "Your disks get turbofucked if the network ever so much as burps" is unacceptable for something you expect people to actually use for real.

A glance at the spec reveals that TCP was chosen to provide reliable, in-order transmission of NVMe payloads. TCP is quite able to recover from intermittent transport errors. You might consider reading the first paragraph of sections 2 and 3.3, as well as sections 3.4, 3.5, and the first handful of paragraphs of section 3.5.1 of the relevant spec. [0]

If you're truly seeing disk corruption whenever the network so much as burps, then it sounds like the SystemD guys fucked something up.

[0] <https://nvmexpress.org/wp-content/uploads/NVM-Express-TCP-Tr...>

File history, sharing and user management are some of the common ones I can think of.

Reply on news.ycombinator.com