Like many here, I try to keep computer audio simple. My music library resides on a single external bus-powered Oyen firewire drive. Until recently, this was a 1TB Samsung HDD. I've now replaced it with a 1TB SSD, but what is of relevance here is what happened after about three years of constant, daily use. Like many drives (HHD and SSD), it started to fail. However, it wasn't obvious to me, at first, that the hardware was failing. I am still not certain. When I copied the contents of the library, I noticed some files failed to copy:

 

I recently found out the hard way that a music file can become corrupted without the md5sum or sha1 checksum changing.

 

This is because the checksum is a signature of the bit content of the data fork, whereas various extended attributes can (and do) change all the time in the resource fork of the file that is present on filesystems such as Apple's HFS+ filesystem.

 

If the resource fork metadata (not to be confused with music file tag metadata, which belongs to the data fork of the file) becomes corrupted, it can prevent copying or playing the music file. (So in this extreme sense, SandyK is right, files with identical checksums can sound different, but it is important to keep in mind the difference in this case is due to file system corruption).

 

This raises a problem: Typically we check (if at all) for file corruption based on the checksum of the data fork. Does anyone do this for resource forks? Does zfs or btrfs self-healing take this into account? Or are resource forks subject to bitrot that can go undetected?

 

HFS+ has a reputation for being a fragile file system. I decided if I wanted to definitively address this problem, I wanted one of the more robust "self-healing" filesystems like sfs or btrfs on a NAS. Although replacing music files that become corrupted is a pain in the arse, it is at least possible. However, for my laboratory experimental data (including many 100s of GB of X-ray diffraction images), the data files are irreplaceable. Similarly, family digital photos cannot be replaced. I decided to get a NAS as part of a (redundant) data backup and storage strategy for my research group, and this would also allow me to keep a remote backup copy of my music library (and family photos) at work. An added bonus is that these would be accessible from any computer at work (or anywhere else).

 

Since I have a computer hardware budget and limited time, I didn't want a DIY project. I wanted a NAS that would essentially be plug-and-play with minimal configuration. After a lot of consideration, I went for a ZFS-based freeNAS with four disc drives that could be configured in a raid array. The FreeNAS mini runs freeBSD, which happens to be the flavor of unix from which Darwin (OS X unix) was derived. The main point is it is a fairly standard unix operating system, so anyone familiar with linux, OS X, or other flavors of unix should be able to find their way around. The FreeNAS project is an open-source effort designed to allow a NAS such as the one I purchased, or one you might choose to assemble yourself, to be configured from a semi-user-friedly web-based GUI. (Although I am actually more of a unix command-line-oriented individual, rather than a GUI fan, I actually found the interface to be quite helpful. In fact, my only gripe is that the way this thing works is that changes made within the GUI persist, but many system modifications one might try to make on the command-line get wiped out upon reboot (or sooner). At first, this irritated the living shit out of me, but now I have come to appreciate the point of doing things this way, if one is administering what the vendor insists upon referring to as an "appliance." If I ever decide the GUI does more harm than good, I can always kick it to the curb, but for now I have surrendered to its functionality for the most part.)

 

Hardware

 

The hardware seems to be first-rate. The chassis holds four conventional hard drives, which the vendor optionally supplies, formatted and ready to install.

 

I decided to take advantage of getting everything bundled, and got the largest hard drive option they sell. Their choice is the WD Red HDD, which I guess is reasonably robust, unlike the 3TB Seagate Drive with the 38% failure rate I bought at Costco.

 

All you do is stick the drives in the bays and plug it in. (I didn't realize you have to use the ejection lever to put the drive in properly, or it won't seat on the pins and power up. Customer service got back to me at 7 am local time when I submitted an 11th-hour plea for help via email.)

 

Once you get the discs installed, you have to hook up a VGA monitor temporarily, and a USB keyboard, and issue a few responses to some initialization prompts, and then you can access the web browser-based GUI from the comfort of any other computer on your local network to complete the setup process. Here is what the GUI looks like:

 

The FreeNAS GUI

 

What you see below is the web-based interface that allows you to control the NAS. You have to configure everything using the GUI. The GUI then saves the configuration parameters in a sql-like database file, and from that file standard unix configuration files are generated (and re-generated) upon rebooting (sometimes sooner). This can be a double-edge sword. I quickly learned to stop fighting it, but it still bugs me that I can't over-ride some default settings that appear to be counter-productive or security holes, without coming up with some crazy work-around strategies (one of which I describe at the end.)

 

 

You can save the original factory settings, and each set of changes (and prune the list as you see appropriate), which allows you to go back to and boot into a previous configuration if you run into problems:

 

 

Once you configure the RAID and import some files, you can export all or portions of the RAID file system to your other computers using Apple's firesharing protocol (AFP), SMB, NFS, or other options. The GUI allows you to configure these, and importantly, restrict who can access them and from what computers (using hosts allow and host deny and/or username-based access). Here's a (redacted) copy of the first few AFP exports I created. I am able to mount (for example) my music and photos library from my laptop in a hotel room many miles away (not an option I recommend implementing normally):

 

 

Jails and Plug-ins

 

I mentioned FreeNAS is very intolerant of customizations you might wish to make that are not available via the GUI. Instead, if you want to run a lab website, or a music server or minecraft server or whatever, you can create what FreeBSD maintainers call a "Jail" or sandbox, which creates a FreeBSD operating system nested within the parent OS. In other words, you can run a computer within the computer, and the computer within cannot interfere with or damage or delete files in the parent computer. Its contents and functionality are jailed or sandboxed. A set of pre-prepared jails are made available as "plug-ins" that can be installed from the FreeNAS GUI, or you can create your own jail, as I did, when I cloned my lab's website. These jails get their own IP addresses, MAC addresses, and so forth, and to the outside world look like stand-alone computers. Importantly, these files reside on the RAID itself, and are not clobbered upon reconfiguration or reboot. Although I don't happen to use this NAS as a conventional music-server NAS, you can see there are several plug-in options that would enable you to do this. (You can then export your library from the main filesystem to the jail and mount it).

 

 

Turn off the damn GUI

 

I think having a GUI login with a root password is idiotic. It is even more idiotic to have to type the root password in via http rather than https (the default, although you can, and should, remedy this). It is even more idiotic to broadcast that GUI login page to the universe, and have no apparent way to firewall it off or restrict access to your LAN or vLAN. WTF? Even my attempts to do this in the webserver configuration files got clobbered almost immediately. One workaround I have is to ssh into the machine and kill the webserver, and then start it back up only when I need it. This is not reasonable, and even this won't survive a reboot. I defined two shell functions to try to make this easier:

 

 

I really shouldn't have to do this. Complaining got me nowhere.

 

 

Overall Assessment:

 

Although by no means as simple as setting up an Apple computer running OS X, assembly and set up of the FreeNAS Mini was relatively straightforward, and file exports work as expected. I am even able to do time-machine backups, although I find rsync both faster and more useful. (Time machine creates a monolithic sparse disc image file, so I would suggest not using it for NAS backups, but instead use rsync or the equivalent, especially if you are dealing with a music or photo or movie library.) The FreeNAS GUI and OS, along with the plugin/jail system, gives you the flexibility you need, within the confines imposed by the FreeNAS way of doing things. (The flip-side of the imposed restrictions is they have made administering the NAS fairly idiot-proof, and it spares you the need to learn a lot of zfs jargon and configuration, which looks to me like a fairly steep learning curve. If you have the time and patience and aptitude to DIY, you can save some money, but this "appliance" will save you a lot of grief if you are a time-strapped ADHD-addled borderline computer illiterate like I am.)

 

Additional Information:

 

Wikipedia Article on ZFS

 

iXSystems FreeNAS Mini NAS Review - Tom's Hardware

 

iXsystems FreeNAS Mini 4-Bay NAS Review

 

Things you should consider when building a ZFS NAS

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

---