This is the new breed of network-attached devices that extends beyond storage. Many new home and small office QNAP systems fall into this category. Nobody has coined an official term for these systems, but someone really should. Continuing to call them NAS fails to capture everything they're capable of.
We do have a name for it. It's a very old name with a distinguished history, it's known as "File Server". This is no different then having Unix / Linux / NT installed on a server and then exporting storage to a local network in whatever language / protocol is necessary. Hiding the OS from the customer nor automating the maintenance of the File Server does not change it's designation or purpose. Further if we wanted to install additional services onto our File Server it now becomes an Application Server and since it's an All-In-One device we could just call it a Server. Congratulations on reinventing a 1980's concept.
As for iSCSI in a home environment,
just say no. There is a reason it's not used. Without jumbo frames, and a dedicated VLAN / QoS you are going to be shredding your network I/O. Each 4K I/O block gets broken into three separate Ethernet frames and blasted out across the switch where it competes with every other form of traffic for bandwidth and network I/O. It's heard by the distant end, reassembled in the network buffer, read and then another request is sent out, all without compression or any form of traffic shaping. It's perfectly fine for lab and experimental work but absolutely atrocious for real world work loads. If you have to store and execute data remotely then use SMB via a mounted drive letter or even a NTFS junction via mklink.
mklink /d C:\FolderToInstallStuff \\NASServer\\SMBShareFolder
Will create an entry in the NTFS file table that looks like a folder to everything, except the file storage subsystem, any file operations directed to that folder will instead be redirected to the remote SMB server. Applications will act exactly the same but without having to deal with the issues of having to abstract a block level device over a home network connection. Let the OS do it's job with optimizing network file I/O.
Side note about performance. The real difference between file level and block level access is where the onus of file system management takes place. With file level the remote file server is responsible and must spend CPU cycles and memory for caching the data, on block level your local machine is responsible for doing it. Since local machines tend to have more CPU / memory iSCSI would win in a back-to-back configuration (Client <-> Server) with nothing else happening on the switch, in which case might as well use a cross-over cable. The moment you start placing additional traffic on the network that the iSCSI packets now need to compete with, this starts to change as iSCSI wasn't designed to fight with other traffic nor is the client computer even aware that it has to. Also once your iSCSI storage manager has enough CPU power and memory to effectively manage it's own file shares, that advantage of iSCSI melts away and the performance swings in the other direction, especially as file services are available to all incoming clients while iSCSI is only available to the initiator.
Since these QNAP devices have decently powerful x86 CPU's with generous amounts of memory host side resource contention won't be a problem. It's having to shove 4K random I/O requests over a 1500MTU pipe on a general purpose VLAN with all the other traffic that's the problem. The real solution is local storage for data intensive programs and remote storage for shared media files. SATA storage is cheap, no need to reinvent the wheel in the home.
Facebook
Twitter
Instagram