JonathanM

What speeds do you get if you run multiple simultaneous large reads to different computers?

Sounds like your SAB downloads folder didn't get cleaned out, and since it's a hidden folder, it didn't get moved to the array either. Can you browse your cache disk from your main computer? If so, set your file browser to show hidden files, and look around in the .sabnzbd/downloads folder and see if you can find the backlog of unprocessed stuff.

Post a full syslog that includes the time a large transfer was completed, and server specifications. PSU, Motherboard, RAM, HBA's, hard drive models, etc.

That assumes a STOCK install of unraid. There are some add ons that break unraids ability to setup and partition large disks. It really sounds like this is the OP's issue, which I tried to address with an earlier post.

This. I think there is a setting in Dynamix that disables the constant update that causes the issue. Downside is you have to manually refresh the page to see changes. Or something like that, I don't use Dynamix.

OK jonathanm, I have reconfigured the RPC-4224 so that all 7 drives are running off of one of the AOC-SAS2LP-MV8 controller. I guess I just have to wait and see what happens. Did you remove the extra cards from their slots?

There have been several examples here of failure to add large drives caused by conflicting add on software. Find a post by dgaschk and follow his signature to revert to totally stock, then try to add the drive again. Also, as others in this thread have said, I would NEVER allow a drive into any position in my array without passing at least 1 preclear cycle, I typically do 3 cycles. If you want to use your array while this is going on, my advice would be to put the original parity drive back, and run a correcting parity check to get back protected while you are preclearing your new drives. If you have enough drive slots, you could preclear multiples at the same time, just be aware of memory limitations.

Sounds like a good plan, especially since you will have copies of the data you are manipulating, so risk is reduced. The only thing I can add is to use a checksum verification on the old and new data, just to be sure. Either use a checksumming copy program like teracopy, or create MD5 files before you start and verify after copy. Do you already have a 4TB parity drive in place, or is one of the currently preclearing drives going in that slot?

No help for the original issue, but I think it's critical that you understand why you can see and work with a disabled disk. This ability is what allows unraid to rebuild 1 failed disk, so if you don't understand it, you won't be in a good position to work with it. Whenever a write to a disk fails, unraid disables the disk, so no more data is sent to it. Instead, ALL disk operations to the disabled disk are redirected to the phantom disk that is maintained by parity calculations spanning the entire array. You could continue to operate this way, but if another disk fails, you immediately lose access to all the data on BOTH disks that failed. That's why it is critical to deal with a single disk failure promptly, and never run an unraid array (or any array really) with a disk that you suspect is bad. When I first started playing with unraid, I figured, it's fault tolerant, I can have a failed disk rebuilt no problem, so why should I care about the health of my disks, if one fails, unraid will tell me and fix it. WRONG ATTITUDE. It bit me big time, when one disk failed, another questionable disk acted up during the rebuild, and I lost some data. I know that doesn't apply to you right now, I'm just throwing out the info in general. As to your specific problem, try removing 2 of your AOC controller cards and operate off of just 1 for a troubleshooting run, since you should have enough ports to operate that way with your limited drive count. I suspect the three identical cards are causing some sort of timing issue.

Unraid does not do ANY file level correction, EVER. It does not calculate parity on files. There is no protection against file corruption. Parity in unraid only works with a drive as a whole, it does not care or check individual files. Please read this for a more in depth explanation. http://lime-technology.com/wiki/index.php/Parity

Temporarily uninstall (not just disable) the security software on the pc with which you are trying to access the server.

Since you were not using the unraid webgui, you should ask the author of dynamix to investigate. If a bug bit you, it may bite others.

Try deleting the unmenu folder, and start over with the directions. Copy and paste the full session if you are still having issues.

The stock web interface (emhttp) is not restartable, it will segfault if you do what you describe. http://lime-technology.com/forum/index.php?topic=13187.msg182915#msg182915

My recommendation to run Joe L.'s preclear script on the drive has two purposes, the first is to check the health of the drive. If you are at all concerned that the drive is not healthy, I'd run multiple passes of the script. The preclear script is excellent for weeding out bad drives, as it reads, writes, and verifies every single sector that unraid will use. The second is to speed the addition of the drive into an already parity protected array. If you have an already healthy parity protected array, any new drive must be set to all zeroes so as not to effect the parity calculations. If the drive is not precleared, unraid will take many hours to write zeroes to the drive, during that time the array will be offline. Setting a new configuration immediately invalidates parity, and forces a rebuild of the parity disk based on the current contents of the data disks. After parity has been built, you should immediately do a parity check, to make sure the parity disk can be read error free.

Short/Long pass fine. In that case, if you are planning to add that drive back to the array in another slot, you should probably run a preclear pass on it, so the array won't be down for so long while the drive is cleared. Preclear will irretrievably erase the drive. I'm not sure what you meant by so I'm assuming since you rebuilt that drive slot, you want to add the drive to the array as a blank drive to increase your free space.

Unraid parity is partition level, files aren't considered at all. Start reading here. http://lime-technology.com/wiki/index.php/FAQ#How_does_parity_work.3F As far as the drive goes, how does the smart report look?

The parity rebuilt drive will have exactly the same corruptions as the drive you pulled. Parity has no concept of files, it only puts back the bits exactly as they were when the drive was pulled. Good news is you will have two exact copies of the corrupt drive, so you can try different recovery strategies if one fails. Unraid is not a backup. It's a safeguard against a single drive catastrophic failure.

It's almost like a sliding scale, the more stuff you want to run on your server, the better off you will be with virtualization, assuming your underlying hardware is capable. Many, many people have been running the trinity on otherwise basically stock unraid as you are describing, and it works well. If that's all you really want, the trail is well blazed, and you should be fine just following the guides. If you think you will continue to want to add and modify stuff, virtualization is the way to go. As things change, VM's are easier to update and modify.

Save the log BEFORE you reboot. A post reboot log won't have the relevant information, as the log file is started new at each boot, and old logs are not automatically saved.

Very true, however... if you like the idea of being able to start a job at the console and later check on it or continue it from a telnet login, screen will allow you to access it from either method. Just detach the screen session and reattach it from wherever you like.

This seems like overkill since you just read the data and wrote the parity bit without a drive reported write error. But hey, whatever keeps you warm at night ;-) There have been several instances of a parity build completing successfully, and then not checking ok. It's not just the write operation completing without error, the drive has to actually read that data before it's any good. Controller errors, RAM errors, drives that return seemingly random values for certain addresses, I think I've seen each of those multiple times in all the years I've been playing with computers. Just like a backup routine that's never been restored and compared to test it, a parity build is suspect until proven otherwise.

I think you should be able to accomplish what you want by putting all your drives into a single spin up group.

Uninstall (not just disable) your security suite temporarily. I have seen multiple instances of aggressive firewalls blocking web servers that are inside the LAN.