Newbie here, I have ordered pro version (on its way) and realized today that the release stable candidate doesn't support 3 TB HDD. My parity HDD will be a 3TB WD Red with a bunch of mixed disks, 9 disks total ranging between 1-2 TB. I assume the usb stick will be shipped with the stable version. If I delete the files from the limetech usb drive and load it with the rc v5 candidate, am I good to go? Is the release candidate stable enough to start building my raid server? To begin with, I am not looking for anything fancy .. about 8TB of raid'ed storage, squeezebox server and a usenet client.

 

I thought I did my research on the unraid features before making a plunge but guess not. With a 1 yr boy and a demanding job, hobby time becomes very limited. Help appreciated, thanks folks.

What makes you think that the v5.0 RC8a does not support 3TB disks?  It certainly does as I am using them, and I believe 4TB ones are supported as well although I do not have any in my setup.

 

It is the earlier 4.7 release that is limited to 2TB disks.

My error in original post .. meant to say "3TB unsupported in stable version". I assumed the usb drives will be shipped with the stable 4.7 release which doesn't support 3TB. My concern was regarding:

1. using the pro license. I bought the pro license which will be tied to the usb drive hardware and not what version of unraid it runs. I want to confirm that removing the stable version and replacing it with v5 rc8 should be fine.

2. Given my proposed usage and a newbie with unraid, is there any concern in using the v5 rc as my primary unraid server?

 

#1: The license is tied to the flash drive, not the version of unraid. You are free to upgrade as you wish

#2: You are correct, the USB will be shipped with the latest stable version, which at this time is 4.7 . You can upgrade following the instructions in the release notes to V5. Doing so before actually "building" your server will save you time, as you will basically be able to skip straight to the end of the steps.

 

Now, for the caveats.

 

The latest release at this time, 5RC8a has a bug with samba(its samba's fault, not unraids) that causes issues with adding/removing files from the remote client. Because of this there is a workaround to use a fixed version of samba and just add a line to the go file(located on the flash drive in the config directory) to install that version of samba on boot.

 

The 5 Beta builds and RC's have all been pretty stable, only issues have been with certain setups. I would read up on the RC8 thread to see what these are as I'm not 100% sure, but I'll list what I know:

 

1. Samba issue stated above

2. NFS Stale File Handling issue, not an issue if you don't use NFS, I haven't seen widespread reports of this bug still existing on RC8, but I remember atleast one post on it.

3. Some performance issues, not sure if its related to specific controllers or unraid in general. I personally have noticed NO performance issues.

 

Without knowing exact hardware it is hard or impossible to be able to vet your setup but in my opinion there is no concern with using the V5 RC as your primary unraid server, I do and others do with no issue.

Perfect, what I was hoping for, thanks!

 

My primary unraid access will be from Win 7 pro systems, one HTPC and another laptop for everyday use. I think 'fixed' Samba should do well for these purposes and do not need NFS.

 

I have been considering allocating a 1TB Hitachi 7200 rpm as a cache drive. I have read that it is generally recommended for quicker access times. At some point when I am comfortable with the unraid I may wipe my 750GB WD Black which currently houses Win7 boot and use that as cache drive.

 

Any thoughts on this?

Your cache drive should be as large as the amount of data you reasonably expect to transfer in a single day + ~10-20GB. I normally do not transfer that much on a daily basis so I use to use a 80GB cache drive and had NO issues. Only reason I changed to the 500GB drive I currently use is I wanted the 80GB drive for something else.

 

The cache drive comes in handy for a few reasons:

 

1. Faster transfer times

        -Note I said faster transfer times, access times will be the same with the exception you probably will not need to wait for the drive to spin up. The cache disk speeds up transfers because without it you are transferring directly to the array which means that parity is being updated at the same time, slowing down the transfer. Using a cache disk the file goes to the cache first(it will still appear in the share you send it to but will not be protected by parity until it transfers to the array), then during the set time the mover runs, default is 3:40am I believe, the data will be transferred to the array. The goal is for it to be transferred when the server is not in use so the slower writes do not affect you.

 

2. A "built in" apps drive.

      - The cache drive can also have "cache only" shares, which are shares that will not be moved to the array and stay on the cache drive. These are good for apps as it is available before the array is and it will allow your array to spin down when not in use.

I have been considering allocating a 1TB Hitachi 7200 rpm as a cache drive. I have read that it is generally recommended for quicker access times. 

The cache drive does absolutely NOTHING to enable quicker access.  If anything, it slows it down. (because both the protected array AND the cache drive must be scanned when accessing a file to read)

 

The cache drive does enable faster "writes" to the array, as the files are written without parity protection to the cache drive.  That speed increase is at the expense of no parity protection until later when the file is copied to the parity protected array by a batch process in the middle of the night.  (that copy takes as long, or longer than the original write without a cache drive would have taken)