SSD

This is a PCIe 3.0 card with x8 bus. It is overspeced for most anything you'd need to use it for, but it is new (as opposed to used on eBay). $99 for a new 8 port card is a very good price https://www.newegg.com/Product/Product.aspx?Item=9SIAD5G5JG6318&ignorebbr=1 I like the PCIe 2.0 version, the LSI SAS9201-8i,, and it works just as well for most people. They are closer to $50 on eBay. I have the -16i and -16e versions of this card and can attest they are excellent and work well with unRAID.

Here is a link that explains how to upsize parity and make the old partiy into a data disk in one pass. It includes some safety steps to increase chances of success.

You need to have an empty drive in the array to begin the migration process. If you add a drive that has not been precleared, unRaid will clear it. You will then format it to xfs, and copy the data from one of your rfs drives to.this new drive. Afterwards, you will format that rfs drive (the one you copied to the new disk) to xfs. (Formatting simply writes the xfs format, which unRaid reflects in parity.) You can then copy the next rfs drive to the disk that you just reformatted. Repeat over and over until all disks are copied and you'll be left with an empty xfs disk. You should never have to clear another disk.

The SuperMicros are only rated at 3Gbps because 6Gbps didn't exist when they were originally made. My drives in there report 6Gbps connection speeds. Pretty academic, though, because no spinner can saturate even the 3Gbps bus.

It used to be the default. In the version I run it still is the default. I wish we had better tools in the event of a parity error - to research and maybe figure out why it was caused, but lacking something like that, there is not much alternative to allowing the parity to be updated. I DO strongly recommend that people create md5 (or similiar) checksums of all of their files, so in the event of possible corruption, you can positively determine if corruption occurred, and identify which file(s) were impacted. It is a bad feeling to suspect you have corruption with no way to know for sure or identify likely suspects. But having parity out of sync with your data disks is a bad situation. Even if one of your data disks is possibly corrupted, you would want parity consistent with that corruption so that the rebuilding of another disk can be performed correctly. But I will tell you, I have such md5s and never have had a hard shutdown cause corruption on my disks. Updating parity was always the right thing to do. I do suggest getting busy on the XFS conversion! Here is the link to the sticky to point you to the wiki and discussion thread.

There are two types of parity checks - correcting and non-correcting. You can run non-correcting over and over and nothing is ever fixed. If you run one correcting one, the corrections are written and you are done. One of the great mysteries of unRaid have been an odd flip flopping behavior where a correcting check fixes a set of parity errors, and then a subsequent check flags exactly the same sectors and flips them back. This had been documented 4 or 5 times but is exceedingly rare. I think you just never ran a correcting check. In the logs it will say CORRECT or NOCORRECT when the check is started. On the Reiserfs front, two words - get off. It was a good filesystem in its day, but with larger drive sizes it slows down dramatically, causing time outs and poor performance. Its limitations have justifiably lead to disuse, and its disuse lead to less diligence in making required updates. One update made it into the golden release that corrupted people's data. The fewer the people that use it, the higher the risk bugs creep in. And the one place you want no bugs is in your file system! The final reason, if those are not enough, is the author brutally killed his wife and is rotting in jail. And if you think he's sorry, he was just involved in a lawsuit with his children. I would not want to honor him in any way by using an invention of his evil mind. There is a sticky with a link to an excellent wiki by RobJ on how to convert, and a very lengthy discussion thread. I recommend XFS.

Awesome Shark build! I have a Sharkoon Rebel 12 with 4x SuperMicro 5in3s. Only purchase ever from Amazon in Germany. Also took some dremeling to use the top slot. Very tight fit! I love these cases for unRaid. Great choice!

ROFL. I see all! Normally after a hard boot, unRAID will initiate a correcting check. Your log is truncated, and I cannot see the log entry for where the check was kicked off, which would confirm a correcting check was kicked off. But I expect your parity errors are behind you. You can run a second check to confirm.

These are not disk errors but sync errors. The diagnostics file would allow more research to see if you are having disk issues, but most common reason for sync errors is a dirty / hard shutdown, for example if you had a power cut or wife tripped over the power cord while vacuuming. Normally a correcting check cleans this up with no trouble. That's because most modern file systems handle this type of calamity without much difficulty, whereas unRAID's filesystem-less parity disk is more likely to lack updates. Since the correcting check relies on the data disks, and updates parity, this is a good thing.

Server in a closet sounds a little constrained. Do you think you'll have adequate cooling. I would monitor it to make sure. Was going to make a comment about it coming out of the closet, but decided to keep to myself.

Look on the tools tab. Many people with unRAID arrays become somewhat anal about having parity protection. A second without it is a second when you are at risk for data loss if a drive fails. Rebuilding parity is a relatively slow process, and until it is done you are not protected. For that reason, many people prefer not to remove a disk if they can help it. After all, eventually you'll need more space. But it is pretty easy to do. You just tell unRAID to foget about your current array (New Config) and then redefine the array without the disk you wanted to remove. Just make sure to assign regularly parity to parity. If you have dual parity, you'd have to rebuild the second parity (probably best to leave it out, and then add it back after the new array is started and stopped once. And it would rebuild it.) There is a trickier way taking advantage of the fact that a drive full of binary zero is "invisible" to parity. So you can fill a disk with zeroes while it is in the array, then do the New Config telling it to trust parity. And define the array without that disk, telling the New Config to trust parity. Because you zeroed out the disk, parity will still be accurate. And you would have silently removed the disk (destroying any use of the disk as a backup of the data is contained). You can do a fancier trick to pull out two drives - just clone a disk (sector by sector). Two identical disks cancel each other out parity wise (at least single parity, maybe not dual) . But anyway, I digress .. I used to be the kind of person that looked for these "maintain parity at all costs" methods, but not any more. Instead, I recommend running a parity check before removing it, and looking at the SMART attributes for every disk, before and after. By comparing the before and after values, you can see if any of the disk is having signs of impending failure. Values like reallocated sectors and pending sectors on the rise are danger signs. If you see these problems it is not a good time to remove a disk (except THAT one)! But if the before and after SMART values for these are both 0, and nothing else is looking concerning, doing the new config and rebuilding parity is very low risk. Enjoy your array!

I am not sure about unassigned devices, but know that the smartctl program (the underlying tool all unRAID tools use to get SMART data) DOES have support for SOME USB chips. I was trying to do a preclear from an external enclosure couple years back, and tried the USB options and got one to work. I proceeded to patch the preclear script to use that option (not recommended for the casual user), and used it to preclear that disk. Below is the relevant option from smartctl ... -d TYPE, --device=TYPE Specify device type to one of: ata, scsi, sat[,auto][,N][+TYPE], usbcypress[,X], usbjmicron[,p][,x][,N], usbsunplus, marvell, areca,N/E, 3ware,N, hpt,L/M/N, megaraid,N, cciss,N, auto, test

I am having a hard time following some of these questions. The principles are pretty easy. 1. Each disk is a long string of 1s and 0s. Parity is based on those 1s and 0s. 2. Whether parity is even or odd is not important. That is a low level decision with no impact on the end user. 3. If you format a disk, some of those 1s and 0s get updated. Parity is updated. 4. If you write a file to a disk, some of those 1s and 0s get updates. Parity is updated. 5. If a new disk is inserted in an array that is all 0s, it can be inserted into the array and parity remains valid (0s don't affect parity) 6. If a new disk is inserted in an array that is not all 0s, parity will be made invalid (possible with parity trust procedure) 7. If an existing disk is taken out of the array, Parity is made invalid (possible with parity trust procedure) 8. The order of the disks is unimportant to single parity. For the "parity2", ORDER is significant and rearranging that order will make parity2 invalid. (possible with trust parity procedure) Using those principles, you should understand ... 1 - Parity is very dependent on not just what data is stored on a disk, but how its content is stored (what sectors, how filesystem works, etc.). Two disks can contain the exact same files, but yet they are not interchangeable with parity. 2 - Parity can be used to rebuild a disk. It can't be used to rebuild a single file. 3 - If an original disk was RFS, and you rebuild it, the restored disk will be RFS. If you fool unRAID into thinking that disk is XFS, unRAID will report it as unmountable. It is then easy to click a button and reformat it as XFS. Be careful about reformatting disks you believe should contain data.

Which would cause a re-read of the source files. Is there a tool or way to structure such that the source files are read once, the destination files are written once, and the destination files are read once? (like Teracopy but doing it local on the server)

That was my fear. So, on a single computer and knowing the files are NOT going to already exist at the destination location, rsync is no better than cp or mv. Correct?

A little off topic - but thought I would ask this question of the rsync fanboys. How does rsync verify that file written is same as source file? In particular, does it do a read of the written data as the verification? The reason I ask is based on your statement ... "In fact, copying between different computers is pretty much why rsync exists" When I researched this a while back, I thought rsync was focused more on the data being received accurately from the remote computer, and it was not 100% clear that it verified the written. There is a "bug" (Tom may disagree with this characterization) that may or may not have been fixed. I encountered it several times with a pesky problem I was having - in which my target drive was dropping from the array during a copy. You would think, in that scenario, that PARITY would be maintained properly even if the target disk failed. But that's not what happened. The write to parity DID NOT OCCUR or was not done correctly. But the OS never got an error or indication that anything went wrong, and the copy of subsequent files continued unabated. All prior and subsequent file copies update parity properly but that one I/O, the one that triggered the kick, was not reflected in parity. The reason I found this was I was using Teracopy. Teracopy does one read of the data from the source computing the MD5 as it goes and copying the data to the destination. It then reads the destination file to compute its MD5. If the MD5s don't match it reports the problem. I was shocked when I saw Teracopy report the MD5 verification failure in the middle of a sea of files, but it lead me to my investigatory steps which led to my bug analysis above. I have been using rsync and really like it a lot. It is considerably faster than Teracopy (leading in part to questioning how it works). I always check to see if a disk kicked before deleting the source files after using rsync. Since using it I have not had any disks kick from my array during rsync, so have not been able to prove or disprove if the "bug" is fixed or if rsync is detecting the problem if this bug remains.

Use a deep C-clamp to bend the tabs flat. Do not try to remove them.

I think short spindown times are bad for drive health. (Mine is 5 hours in attempt to only have one per day). It is very hard to prove what is bad and how bad. But my research is that it is better to run a drive too hot than to let it go from cool to warm frequently. If Tom were to implement this, I think that he could have a "convenience turbo write mode" that would not count disk accesses for turbo write purposes against the spindown timer. And that unRAID would take the the system out of turbo write when a drive spun down. This would enable turbo writes when all disks were spun up for other purposes, without stopping them from spinning down. The cutover from turbo to non-turbo write if writes are in process would be a little tricky - but Tom is a smart guy and would figure it out. There would be no reason not to use this convenience mode. Not saying he would do this, but would be an option.

Very cool! A lot of people will really benefit from this!! But, thought I would explain some potential usage pitfalls. This feature does not just take advantage of time other drives happen to be spun up, by its very nature time drives are spinning up will elongated, and in some cases, drives will be prevented from spinning down. Basically the spindown timer countdown on all drives will be reset after any write to the array. And until the array is quiet (no writes) long enough for drives to spindown, turbo write is going to stay on. If you spin up your array - within 5 minutes (with default settings above) turbo write mode will be enabled. You would not know how long you have to wait until turbo kicked in (1 second to 5 minutes). If a transfer were in progress and you said - hey, it'd be nice if turbo were on, you could spin up the array and in a few minutes it would engage. If you want instant, though, this would not give you instant. A shorter interval would help, but there may be negative implications to checking it very frequently. And if you manually spin down at least one disk (assuming disks allowed to be spun down is 0), turbo write mode is disabled within that same time interval. This would not be foolproof. If you spin down some disk(s), and then before the interval, a new array write occurs, the disk(s) would spin up again (since turbo write is still enabled) and the write is performed, and turbo write would not be turned off. As mentioned, having a docker image on an array disk would all but guarantee your array would never get out of turbo-write mode with this plug in, even if you are manually spinning down disks. You would not want to create a situation where your disks spinning up and down frequently for no useful purpose. After a parity check, fresh boot, or if there are frequent writes to the array, array drives may never spin down unless there is manual intervention. Using the feature to force turbo write off (probably late evening and after mover runs) would help. But using this plugin will result in more drives spinning more of the time (not just during faster writes). Those running power efficient arrays might find their electric bill inching north. A person might think a shorter spindown interval might be in order so that turbo write would get disabled "naturally" more of the time. Problem is, shorter spindown intervals will result in drives going through multiple thermal cycles (through your normal usage pattern), which has been identified as a bad thing (maybe the worst thing) for drive health. I have my spindown interval set to 5 hours which largely prevents multiple spinups per day. Balancing settings to allow drives to spin down to shut off turbo write vs setting to reduce frequent spinup/spindown cycles would be tricky. Since my experience is that normal writes are fast enough most of the time, and I'd prefer drives to stay spin down most of the time, I'd prefer to just have an icon on my desktop that turns turbo on for a time interval. That way, if I am waiting for a write to finish, I can quickly turn on turbo write and it will turn off automatically. User scripts with remote SSH execution could be used to set this up. But that is me - I think this plugin would be useful for many unRAID users, and hoping the info above might help get it configured optimally.

Exactly what I do. I will say I had some questions and experimented - like if I move a file in a user share from one directory to another, will unRAID keep the file on the same physical disk even if I am breaking some split level rule. I have found (haven't tested extensively) that a move will move the file onto the same disk if living within the same user share. And if you are moving a bunch of files, it will treat each file separately moving it to directories on the drive it lives on. Pretty slick!

^THIS. Hoping that people following the guide are taking the time to understand how and why the guide works, and synthesizing the basic truth that trurl so eloquently states. RobJ - this was me for 9 of my 10 years using unRAID. In the last year I've begun to embrace user shares, and finally decided they are a good thing. I tend to have some shares that are totally on a single disk, and others that spread out over several. I may combine the ones that fit on one disk together on a single disk (they may have been on separate disks when my disks were 1T, but now that they are 4T and even 8T, it just doesn't make sense to leave so much slack. But typically I dedicate whole disks to shares that span multiple disks. I recently converted my considerable ISO library to MKV to use with Plex. And being able to specify a user share as the destination allowed it to run for many DAYS and overflow onto new drives without a hiccup. A beautiful thing. This is the challenge! I am reminded of the saying that "It is impossible to make anything foolproof, because fools are so ingenious!"

Someone asked a question recently of how quick XFS was to delete files, remarking how painfully slow RFS is. So I had a 1T data migration from one disk to another that I completed as a copy, and then timed the deletion of the source files. It was a total of 2324 files, 194 folders, 1.03TB Took 14 seconds! XFS is quick to delete! No idea how long RFS would have taken. Could have been 20 minutes or more. Yet another reason ...

You can run a script from the command prompt to reset the permissions. Unraid comes with one (at least it used to) called "newperms". You can specify a path, otherwise it processes every disk + cache resetting ownership and permissions. I did a little edit (call it mynewperms) and store it on my flash disk that does not do the sync at the end (the sync spins up all of the disks). So I type: /boot/mynewperms . and it processes the current directory. But you could run (for example): /boot/mynewperms /mnt/user/tvshows You may already be doing something similar, but if not, this will at least keep you going until you get a more permanent solution.

2 - no parity check would occur 5 - yes, parity is maintained Parity is maintained at a very low level. Think of the disk as just a very long series of 1s and 0s. When the disk is formatted, some of those 1s and 0s get changed. Parity tracks those changes. When data is copied to the disk, some of those 1s and 0s are changed. Parity is maintained throughout. The only way parity is not maintained is if you access a disk very directly so that unRaid has no way to detect a change to a disk. For example, if the disk is removed and put into another computer and updated. Parity cannot be maintained. But it is not necessary to remove a disk to write to it outside of its array, but you have to work at it and no wiki instructions or posts are going to direct you to do those sorts of writes. Enjoy your array!

My movies are pretty high bitrate (bluray images) and typically playing HD audio. Definitely had trouble when running a parity check at the same time. But its true that the bandwidth to play a movie is nothing compared to the bandwidth to do a copy. It might take only a few minutes to copy a movie that takes 2 hours to play. But what if I'm doing something more demanding, like running md5 comparisons. (I sometimes run a bunch of whole disk md5 checks in screen sessions as an alternative to a parity check to confirm I'm not seeing any corruption). Or copying new files to a backup server. Or maybe running a transcode to download movies to a lightweight media. Lots of things can demand enough bit rate to cause the I/O to thrash if running in parallel to a lengthy write that demands all hands on deck. But, as I said, for lengthy operations I would definitely turn on turbo write. I did my RFS to XFS conversion with parity disabled. If I'd had an option to do it with turbo write and get rear full speed writes, I might have done that.