What a NAS should and should not be

This is one of my rants. Some people may disagree with the “bias” of the following. But I, killermist, WILL NOT assist anyone in doing any of the things listed below. Those things are things that a NAS should not be doing.

A NAS should be many things.

First and foremost, a NAS should be a storage system. In order to be a storage system that is useful (what good is storage if you can't get it to store or retrieve things?), it must include file transfer protocols (some of which are referred to as “streaming”, which is a fairly useless designation, in general). This carves out a giant area that a NAS should do. And it should do those things expertly. ZFS creates a very stable storage platform. UFS can be used if you don't care about the integrity of your data, because it doesn't checksum the data, and it will gleefully return corrupted data to you as if it were 100% healthy. The list of valid and useful protocols for reading, writing, and moving files is quite comprehensive. NFS, SSH/SSHFS/rsync, SMB and HTTP make up a very comprehensive and useful block. Bittorrent, as a long-running, random availability protocol adds some very useful flexibility. AFP and novelty protocols like UPnP or iTunes add some misguided but commonly requested stuff and can round out a protocol set pretty completely.
That being said, there are a good number of things that a NAS should not be. Further, the list of things that a NAS should not be are things that really should never be supported. Asking me how to install ANYTHING will likely red-flag you as someone that is probably beyond help.

Hint: A good NAS, capable of using the power of ZFS is probably based on FreeBSD. It is probably NOT based on Linux (mostly because of license reasons). So, while some knowledge gained from learning to administrate a Linux system may apply, A LOT of how Linux works is completely invalid in dealing with a good NAS distribution. For almost every action in a good NAS system, using the CLI (SSH or connected screen/keyboard) is entirely the wrong method since the WebGUI should be where configuration changes are made. Furthermore, the "sudo" command, that many Linux people have grown accustomed to, does not exist. Asking why it isn't “installed by default” or why it “can't be installed” is likely to be met with groans and facepalms. 

Among the things that a NAS should not be are the following items, which make up a non-complete list.

• Usenet downloader - You should be using some other machine to do that. Using the NAS to store the results, through a mounted share, great. But A NAS should not be that. There are many low-cost, low-power solutions for little headless tasks like that. Pushing the NAS to do them is not wise.
• Database server - Again, using another machine to run a database server, and storing the database data on a NAS, great. But a NAS is not intended to handle database serving duties. Again, many low-cost, low-power solutions exist to do this. Hey, it could even be your Usenet downloader box…
• Media transcoder - This includes the (misguidedly included) transcoding in UPnP. The processing power and ram of the NAS are supposed to be used for moving hard drive data to/from the network, and not mangling that data along the way for “compatibility” with woefully incompetent devices. If your device isn't compatible with your media, then either fix the media or fix the device. Transcode the data yourself, or get a media player that works right. And no, game consoles are not a good choice for playing media. Anyone that tells you otherwise is lying to you, possibly because they've been lied to them-self. Programs like Handbrake make it really easy to transcode your videos into a format that competent devices can play. But it will require another machine to chug away at the video for a while, depending on the quality level you're demanding of it. But demanding transcoding from the NAS will only slow things down and make responsiveness worse.
• Virtual Machine Host - Again, the processing power and ram of the NAS are supposed to be used for moving hard drive data to/from the network. Wasting your CPU time or memory on running virtual machines means that those resources are unavailable to other more important tasks, like making sure the data can get to/from the network in an expedient manner. In particular, if your NAS only had the recommended quantity of ram for the size of your ZFS storage to begin with, it is especially unwise to take any of that ram away. Even the setup, configuration, and especially troubleshooting of jails (which are virtual-machine-like), which tend to be an included technology in FreeBSD, are a bad idea. So, when someone sets up a jail, and then breaks anything, they will find no help from me for fixing their mess.

Common nonsense

To address some grumbling I can already hear forming, here's some retorts to what I know people are probably about to ask:

• “But, bittorrent is included in a number of NAS solutions. Why not have [X]?” – Transmission is an annoying double-edged sword. It uses the bittorrent protocol to help move files to and from the NAS. Just like NFS, SSH, or SMB. This makes it a valid and useful protocol. In particular, this is a question most commonly asked by people wanting Usenet downloading or other file-leeching mechanisms. Neither of these is a server-like function, which is pretty essential to how a NAS works. If I had to choose to either add these other non-server functions or to remove bittorrent, I'd willingly jettison bittorrent as a supported protocol for the sake of the rest of the system.
• “But my media player uses UPnP and needs things to be transcoded on the fly.” – Get a media player that isn't crap. TV and game console manufacturers have gotten really lazy and bought into the lie and simplicity (stupidity) of adding a broken protocol that then permits them to slap on the “media ready” sticker to their product. Consider these: 
  Scenario 1, I transcode my media once on a client machine and store it on the NAS to play to my media player using SMB. I spend the CPU time ONCE ONLY. I'm also doing it on a machine that isn't the NAS, so the network isn't suffering from a slowed NAS while the encode occurs. And I'm left with a nice pretty file as the result of that spent CPU time. Two, three, 10, even 100 devices can all play video via SMB with no problem provided there's enough network bandwidth and raw disk speed. 
  Scenario 2, some fool uses UPnP to stream files to some broken thing, like PS3/4 or Xbox-something. Every friggin' time a file gets played, CPU time must be wasted (more energy usage and cost, duh) to reencode it on the fly. Worse, all this wasted CPU time leaves no result for having been wasted. Further, because the NAS (and not some other machine) is wasting CPU time encoding, every other task on the NAS has less CPU time available. Simultaneous encodes because of simultaneous viewers can seriously waste CPU time and kneecap NAS performance.

Originally from what_nas4free_is_and_is_not.txt · Last modified: 2015/06/01 09:15 by killermist