JonathanM

Are they healthy? Unraid needs perfect hard drives, so be sure that at the very least all the drives can pass a long smart test with no errors.

Mount it using the Unassigned Devices plugin and add the mount path with the slave r/w option to your container as a new path mapping.

I don't understand. I thought we were discussing the hardware you were planning on building an entirely new array from the ground up. If all the 8TB are purchased and in use, then definitely DON'T buy more 8TB drives for the new build. So for the initial loadout of 40TB I personally would get either 6 10TB or 5 12TB drives, depending on the deals, leaning heavily towards the 12's, for all the reasons I outlined in my first post in the thread. Encryption is what you make of it. You can set it up super secure, which can be a little bit of a pain to deal with on a daily basis, or you can set it up so the only protection it gives you is the individual drive is no longer readable out of context. In ANY case, encryption DEMANDS full backup. Many of the standard easy recovery procedures are either much harder or impossible to do with encryption in place. You are adding much more complication, so the payoff better be worth the effort. I personally use XFS, as the benefits of BTRFS came at too high a risk for me. Your risk profile is different than mine, so you do you.

Only add drives to the array as you need the capacity. Don't populate all 18 data drives, only put in what's needed to hold your current data load plus 1. So, if you have 50TB you are going to load, only put in 8 data drives, for a usable total of 64TB leaving 14TB free. When you get down to 8TB free, add another 8TB. Leave the rest on the shelf if you already bought them, or better yet leave them on the store shelf. ALWAYS keep one physical drive slot empty, if that means sizing up replacement drives, then do it. The number of times I've seen on this forum where it's been useful to have an empty slot for troubleshooting or recovery purposes is countless. One of Unraid's great strengths is the ability to add drives as needed instead of trying to plan far into the future. Fewer drive slots in use equals fewer failure points, less power and heat, ability to pivot to newer technologies as they emerge, both hardware and software. When you land on a format and encryption decision, you can change your mind as you add new drives, if the tech or your needs shift. Each new drive can use a different format and still participate in the array as a whole, either in the parity array(s)*(7.X?) or cache pool(s)*(6.9.X). You can use new drives as you add them to move data from older obsolete formats and strategy, keeping the ability to refresh your array as things progress. You asked about what formats and such, but I'm giving you the answer to solve the long question, because information that is current will be old news soon enough. Good news is that Unraid has the long term solution, whatever that happens to be. That's how I personally would set up a new build.

Already posted in correct support thread. Don't double post.

Can you elaborate on what you mean by merge?

Spray paint?

I'm betting it would be faster to just transfer over the network than to shuttle the data with a hard drive.

When that happens, if you give it a few minutes then refresh the page it will move on to the next step. The timeout coding seems to be too aggressive, showing failures when the process is actually just slowly completing in the background. Obviously this doesn't apply to real errors, just the ones involving backing up and downloading.

Replace the HBA with an LSI based card.

Just wanted to clarify this. Parity has no filesystem and can't be encrypted, because it has no files. It's also not cumulative, each parity disk uses its own algorithm, and can with the entirety of the rest of the data disks emulate one failed disk. So, with 2 parity disks, you can emulate any 2 data disks as long as the rest of the data disks are perfectly healthy.

Instead of leaving a whole keyboard you could just leave one of the logitech wireless keyboard dongles plugged in. They are around $10 or less used on ebay.

https://wiki.lime-technology.com/Troubleshooting#Re-enable_the_drive

Spin down events are logged normally, spin ups aren't directly controlled by unraid so can't currently be logged. Spin ups happen whenever data is read from a disk, by whatever happens to request it, be it network or containers or vm or whatever.

Depending on how you are looking at it, a raw vdisk CAN and will gradually take up more space, all while showing the final allocated size. VM raw vdisk files are created as sparse, which show the full size, but only occupy what is actually used. Then as more and more writes occur, there will be less and less difference between the two sizes until finally the file will occupy the full allocation. That will happen regardless of actually how much data is IN the VM, unless you are using an OS that understands how to manage that type of situation and it's configured correctly. Windows 7 doesn't know how to properly manage its data automatically, so you have to do things like defragment and fill the empty space with zeroes using a third party utility, then resparsify the vdisk file. To see the actual usage vs total allowed, you can use the du command. At the console or SSH session, cd into the folder that holds your image file, probably /mnt/user/domains/Windows \7 or something like that, and use du -h followed by du -h --apparent-size. That will give you what's actually in use compared to the final allocated size.

Agree in principle, however I think in practice the warning is going to apply to virtually everybody, and the net result is going to be confusion. I'd prefer to see the warning at 32GB, since that seems to be the current sweet spot for pricing. Don't get me wrong, the 4GB is completely accurate, I just don't think it's going to be productive, given that the price difference between a 4GB and a 32GB is very small, thus very little dollar benefit for staying low capacity, especially since the warning is issued AFTER someone already made a decision on some level to use that specific drive. User thoughts, "Purchasing a 4GB drive because the install tool told me to seems like a waste after I already purchased a 16GB stick that was the same price." @jonp, @limetech?

Does the problem hard drive work if it's the only drive in the enclosure?

I just edited that section to clarify just how out of date it was. For SAS, the best choice is any semi recent LSI based controller that has IT firmware available.

Keep in mind that because of the way Unraid works, each file can only occupy a single drive. So you are limited in the size of file that you can write by the free space on any single drive.

For your sake I hope it didn't pop your motherboard.

What I don't get about this whole thread is that it's VERY easy and cheap to get wireless support for Unraid right now, no need to wait for OS support. Wireless game adapters are readily available, and easy to change and upgrade when wireless technology advances, instead of waiting for linux support to catch up.

Just to be clear, you had all the PSU leads disconnected and the motherboard pulled back out for this test? A short to ground would cause this symptom.

Wanted, Manual Import