Unraid 6 Setup from existing machine

[mmmeee15]

Hello everyone,

 

I've read up a lot on unraid, and watched every video from LTT with you guys, and I'm ready to take the plunge into unraid. I have a few potential applications, but for the start I would like to basically transfer over my existing main desktop over to unraid. 
Specs that matter:

Currently windows based

6850k platform

Intel 750 PCIE Boot drive

A few other SSD storage drives

 

My main questions are:

1. How easy will it be to get everything back up and running with my existing hardware, to the point that I had it previously.

2. I want to create shares (will put all the SSD's minus PCIE into parity if possible) to store all my various files, so will that require deleting everything off the drives?

3. Plan on dual booting ubuntu, so how will this affect things like sharing of files etc. 

4. Not planning on having both windows and ubuntu running at the same time, so should be fine to pass the same GPU to both?

 

I will try and provide any other important information.

 

Thank you for your help

[unrateable]

Hi and welcome,

 

a newbie myself but i´ll give it a try

 

1) "to the point you had it previously" ? well, if you want to keep your old machine you need to migrate this current system into a vm in a form that can be used later on the unraid virtualization environment (qemu)

 

2) shares are created on the array. new disks coming into the array will usually get pre-cleared (=check and format) and thus old content is deleted.

pre-clearing is recommended but afaik not mandatory. make sure to backup all the data before starting to build the unraid system with these disks.

you can also start with one disk hanging in the array and then copy the data from the other old disks step by step (hint: via unassigned device and mc or krusader) after that hang the second disk in the array and wash and repeat with the other remainig old data drives outside the array.

 

3) parity drive should be the largest drive (or two drives in case you want dual parity) in the array. a slow but big drive is good enough

 

4) besides the parity drive you will want a data drive (or more than one) and a cache drive (pcie ssd will serve well and is very fast), use the latter for your VMs as well

 

5) i have no experience for dual boot (ubuntu+unraid). I guess you need a bootmanager set up properly to select unraid usb flash stick or your other OS drive. maybe via bios boot order selection . that may be inconvenient. if your mainboard had ipmi it could make things easier if you plan to remotely administer .

 be careful if you plan to assign drives to both OS´. that may lead to corrupt data

 

6) gpu should work fine in both systems since its not possible to run both at the same time

 

cheers

 

 

 

 

Edited November 28, 2017 by unrateable

[mmmeee15]

Thanks for getting back to me. 

 

So basically, to sum things up, it would be best to have a fresh start with everything, including windows, and all respective drives?

 

To specify a few more details, my PCIE is currently a boot drive, with 3 more SSDs in JBOD. So clearly the PCIE will become the cache and OS drive as it's much faster, but is it currently possible to have an SSD array (will likely setup just 1 disk for parity, or maybe just JBOD again, since everything is backed up to a different server regularly)?

 

Regarding the dual boot, I know it is technically possible, But the "leading to corrupt data" is an issue I clearly want to avoid. If the other drives (shares) do not have any OS related folders, but are simply data storage for photos, video, games etc, will this still be a problem?

[ashman70]

SSD's are not recommended for the array in unRAID, they can be used for VM's or cache drives, but that is all.

 

 I would suggest you backup your data, get some non SSD hard drives for your current system and try unRAID. As the previous poster indicated, you can create VM's under unRAID and depending on your hardware, pass a GPU through to them, however you can only do this to one VM at a time.

 

Dual booting should be possible but it would be a bit of a pain in the butt if you ask me, just create the Ubuntu  and Windows VM and then you don't have to dual boot.

 

unRAID boots of a USB flash drive, so the PCIe drive won't be needed, but you may be able to use it for a VM.

[mmmeee15]

Thank you for your reply. 

 

Why are SSDs not recommended?  I know that they will technically suffer in the long term due to the limited writes that you can perform, but besides that? I want to stay away from HDDs in my main rig, since they are rather loud (I have a bit of a problem with noise in my setup haha), and I already have a large HDD server in another room. Basically just looking for speed and silence in my main rig. 

 

Yes, I would only ever have either windows or ubuntu running at any time. 

 

Sorry I should have clarified that point, I meant to say that I would have 2 separate VMs like you mentioned. 

 

And yes, was planning on using it for cache / VMs in some sort of split. 

 

Also, meant to ask, I have a mellanox 40gigabit NIC between my main rig and server, model number MHQH19B-XTR. It was a bit of a pain to get this setup in windows, but I've heard it has native support in linux environments. Since unraid is technically linux, it should work without any issues right?

Edited November 28, 2017 by mmmeee15

[ashman70]

You will have to search the forums on why SSD's are not recommended as I can not remember the reason. It's difficult to say whether your network card will work under unRAID or not, again searching the forums might help.

[mmmeee15]

Alright, will do. 

 

Thanks again for your help. 

[BobPhoenix]

My take on why SSDs are not recommended in the array is that Trim would not work on an array drive because if you did use Trim it could invalidate the parity protection.

[pwm]

But using SSD that has overprovisioning, the drives can give good performance without any TRIM, since they rotate flash blocks through the overprovisioning pool. There is a bit of extra wear on the flash if the drive accidentally copies dead data to a new flash block without knowing the data isn't needed anymore but the copy itself is fast. The really important part is that the drive then doesn't need an "ok" from the OS to be able to erase flash blocks because it erases blocks that aren't part of the file system anymore.

[itimpi]

 

1 hour ago, pwm said:

But using SSD that has overprovisioning, the drives can give good performance without any TRIM, since they rotate flash blocks through the overprovisioning pool. There is a bit of extra wear on the flash if the drive accidentally copies dead data to a new flash block without knowing the data isn't needed anymore but the copy itself is fast. The really important part is that the drive then doesn't need an "ok" from the OS to be able to erase flash blocks because it erases blocks that aren't part of the file system anymore.

I think the issue arises if the SSD ever under the covers changes any blocks that are not part of the current file system.    The unRAID parity protection system requires all blocks to give predictable results on read even when they are not part of the file system to enable failed disks to be rebuilt, so there is no concept of ‘dead blocks’.   I am not sure all brands of SSD handle this in the same way.

 

if running without parity protection then this is not an issue.

[pwm]

45 minutes ago, itimpi said:

 

I think the issue arises if the SSD ever under the covers changes any blocks that are not part of the current file system.    The unRAID parity protection system requires all blocks to give predictable results on read even when they are not part of the file system to enable failed disks to be rebuilt, so there is no concept of ‘dead blocks’.   I am not sure all brands of SSD handle this in the same way.

 

if running without parity protection then this is not an issue.

It's just that a SSD does never change any data reachable by the OS unless given instructions to do so using the TRIM command. The TRIM command is the OS way of telling "this part of the addressable range is not used by my file system, so you are free to erase and prepare for reuse - and if you copy data from one flash block to another, you don't need to copy this address range."

 

It's the TRIM that is dangerous to parity, because it represents a disk write that doesn't pass normal parity computation logic.

 

An SSD that does not use overprovisioning and doesn't get TRIM commands will after a while fill every flash block with data. And when that happens and the OS performs a rewrite of one or more sectors, the OS has to

- copy the flash block content to RAM

- erase the flash block

- restore the old contents from RAM after applying the new writes from the OS

 

This is what makes all writes slow when the SSD doesn't receive TRIM commands. And it results in a larger write amplification since it will do lots of copying of old information that represents file system sectors actually not in use.

 

 

When you have a SSD that uses overprovisioning, then even a 100% full SSD that has never seen any TRIM command still has a pool of erased flash blocks. If the OS writes 2 sectors, the SSD will see if any already in-use flash blocks has room for the data for the two sectors and map in and write this data. The OS always writes full sectors so a 1 byte write will still represent a 512 byte or 4096 byte transfer to the SSD, giving no unrepresented bytes that may trip any parity computations.

 

If the SSD has no used flash block that can fit the new data, then it will pick up one already erased flash block from the overprovisioning pool. It will write the new data to parts of the flash block and map into the LBA address range, while moving a previously used block to the overprovisioning pool and start an erase of it. But still without introducing any unexpected changes to the addressable file system range that will trip any parity calculation.

 

So the main danger is to make sure that the OS never sends any TRIM command - because a SSD that uses overprovisioning can also make good use of TRIM to reduce the amount of unused file system sectors to be copied, when a flash block is moved to the overprovisioning pool and any remaining data has to be copied to another flash block.

[JorgeB]

6 minutes ago, pwm said:

So the main danger is to make sure that the OS never sends any TRIM command

That's not a problem with unRAID since trim doesn't work on array devices, so it's not an issue using SSDs as array devices other than they may or not suffer write performance degradations due to lack of trim.

[pwm]

1 hour ago, johnnie.black said:

That's not a problem with unRAID since trim doesn't work on array devices, so it's not an issue using SSDs as array devices other than they may or not suffer write performance degradations due to lack of trim.

Good to know the OS may not send TRIM. Then it should be OK with SSD. Just a note that it's normally enterprise-level SSD that uses overprovisioning so it's normally only enterprise SSD that can maintain good performance without TRIM and when drive is empty or nearly full.

[JorgeB]

1 minute ago, pwm said:

Just a note that it's normally enterprise-level SSD that uses overprovisioning so it's normally only enterprise SSD that can maintain good performance without TRIM and when drive is empty or nearly full.

 

Yeah, I once had an SSD only array but stopped using it because the lack of trim was clearly impacting write performance after a while, recently in a topic started by @jonathanm I was doing some test to see if manually overprovisioning the SSDs by creating an HPA would make a difference, but this time I wasn't noticing any slowdown even without an HPA, though I used different SSDs this time, 850 EVOs and I believe they have around 10% overprovisioning from factory while the SSDs I used previously I think don't have any, so that can explain the performance remaining good.

[pwm]

I don't think you can manually overprovision - the drive needs to keep a pool of off-line flash blocks that it can erase in the background so it never ever needs to wait for an erase while writing new data. That's why write jitter time is an important measurement when benchmarking drives for enterprise use. Extra important in a high-end RAID where you don't want a one of the drives to require extra time for a write.

 

It doesn't help with a drive specified to handle 100 kops/s if a single write now and then needs 1ms extra, representing more than a 100-fold slowdown or 100 lots writes.