Early questions


Recommended Posts

I'm hoping for some support on a few questions:

  1. Any issues with my plan to evaluate on a test PC and then potentially move to the hardware I'd like to be on long term once I've, presumably, determined that I want to move forward with unraid? I assume I'll be testing longer than 30 days so I may end up purchasing a license on my testing/learning PC and then needing to move that license to the long term PC later - am I able to later set up a trial on the long term one, move data over and then move the license to that one permanently?
  2. Can I move the USB key and license and drives from the testing PC to the long term PC with all data etc in place or do I need to install unraid again on the new system and configure it there, then copy all data to it? (I assume new install).
  3. How do the Seagate SMR drives that are shucked from external enclosures do? Are they bad as parity drives?
  4. NAS specific drives aren't required, correct? Some forum reading seems like they aren't though opinion is split as to whether they are worth the upgrade.
  5. Am I able to later increase the size of my parity drive if I start with an 8TB and later want to increase it to a 10TB parity drive? What would this entail?

Thanks.

Link to comment

1). Unraid is largely hardware agnostic.    The license is tied to the USG flash drive so moving that to another machine is all that is required to move Unraid to the new machine.

 

2).  Yes.   Data will move intact as long as both machines recognise the drives with the same serial numbers (Unraid tracks drives by their serial numbers).

 

3).  No idea.    I have Seagate 8TB SMR drives (but not shucked from enclosures) as data drives and they seem to work fine. 

 

4). NAS drives are not required.    However they might make sense as parity drives as they workthe hardest.

 

5). You can always swap a parity drive for a larger one.    When you do Unraid has to build parity on the new drive from all the data drives.

 

  • Like 1
Link to comment

I think the answer to question 2 sort of answers question 1 so I will go with that.

 

You can move the USB key with its license, and the disks with their data intact, to another computer any time you want to.

 

NAS specific drives aren't required.

 

You can increase the size of any disk in the array, including parity, simply by replacing it with a larger drive and letting its contents rebuild from the parity calculation. In the case of data drives, no single data drive can be larger than parity.

  • Upvote 1
Link to comment
1 hour ago, itimpi said:

3).  No idea.    I have Seagate 8TB SMR drives (but not shucked from enclosures) as data drives and they seem to work fine. 

So you have them running off of USB, connected to unraid and that works fine?

 

1 hour ago, trurl said:

NAS specific drives aren't required.

Is there benefit for the parity drive to using one?

 

Also, can you point me to a list of pci/pcie cards to add sata ports (located in Canada)? Thanks.

Link to comment
17 minutes ago, aqua said:

co you have them running off of USB, connected to unraid and that works fine?

No - I bought them as bare SATA drives.    I would never recommend running with USB drives in the array as USB tends to be a little unreliable and the drives thus susceptible to dropping out unexpectedly. (as well as having potential performance issues).

 

17 minutes ago, aqua said:

Is there benefit for the parity drive to using one?

Other than the fact that they are better rated for sustained loads then no.   The SMR drives seem to work OK as parity drives if you are only writing a relatively small number of large files to the array as those are serial writes.   They tend to perform less well with many smaller files as the SMR technology does not handle that so well.

 

17 minutes ago, aqua said:

Also, can you point me to a list of pci/pcie cards to add sata ports (located in Canada)? Thanks.

HBA cards based on the LSI chipsets are recommended.   Avoid getting ones based on marvel chipsets.

Edited by itimpi
  • Like 1
Link to comment

Will there be any issues transferring the USB key over to the new system if the old system doesn't have a UEFI BIOS and the new one does? If for some reason it doesn't transfer over, am I going to have to wipe the drives that were in that old system?

Link to comment
4 minutes ago, aqua said:

Will there be any issues transferring the USB key over to the new system if the old system doesn't have a UEFI BIOS and the new one does? If for some reason it doesn't transfer over, am I going to have to wipe the drives that were in that old system?

No.   As long as the new system can boot from a USB drive in either ‘legacy OR UEFI mode you are fine.   People regularly move their systems to new hardware with no issues.

 

The only thing that tends to cause problems are hardware based RAID controllers for adding extra SATA ports as such controllers tend to mangle the serial numbers of the drives.  

  • Upvote 1
Link to comment

Also in addition to the Controller it needs to be Flashed to IT Mode not Raid. Often I’ve seen HowTo’s or simply found them already Flashed. I think I bought my LSI off of EBay for $57 shipped to the US. 

 

Ive built my first system many many years ago and the only thing still original is my Case and my USB stick. I’ve Swapped out literally everything multiple times because I wanted more or less of something and the only problem I’ve ever had was avoiding the Death Stare from the Misses.  

 

Just make sure you backup your USB stick somewhere and shuffle everything around all you want. Just keep in mind on a Paid License your license lives in the USB/Config folder. You can get help from Limetech if anything ever happens but try explaining that to a 7, 12 and 40 year old who can’t watch their videos now. Lol

  • Upvote 1
Link to comment

Thanks for the help so far. I think I'm in a position to get started tonight or in the next few days as the test system is assembled. I'm tempted to install the latest release candidate rather than the 6.6.7 stable - any thoughts on that? 

Link to comment

No reason not to go with the Release Candidate.   It is thought to be very close to going Stable anyway.    The RCs tend to be stable as long as you do not have any hardware specific issues and even then it can be a good idea so such issues can be reported and fixed in time for the next Stable release.   You can always revert to the Stable release if necessary.

Edited by itimpi
  • Upvote 1
Link to comment
1 hour ago, itimpi said:

No reason not to go with the Release Candidate.   It is thought to be very close to going Stable anyway.    The RCs tend to be stable as long as you do not have any hardware specific issues and even then it can be a good idea so such issues can be reported and fixed in time for the next Stable release.   You can always revert to the Stable release if necessary.

Thanks. I believe I saw comment that it was close to going stable as well, which is why I was thinking of just starting with it.

Link to comment

A few more questions (side note: not intending VMs, just NAS and some dockers like sab, sonarr, radarr, duplicati):

  1. I plan on adding a cache drive later but not on the test build - is it easy to move dockers etc over to the cache drive later or do I need to set them up again? I assume there would be some setting where I can say where the data for them exists and I just change it, correct? 
  2. My current server has a bunch of smaller drives (2TB WD Greens) than I don't intend to move to the unraid server, but I guess I could use them as cache drives to reduce wear on the main drives until I get SSD cache, correct? Is this dumb and I should just get a SSD cache right away or something worth doing in the meantime?
Link to comment

I just went through a migration myself, I don't think its worth the hassle to use green drives as cache, unless you are creating a number of temp files that would go away before mover runs it's not really saving a ton of wear and tear on the array drives and certainly won't be any faster than just writing to the array. As for moving files later, there is a function in the plugin "Fix common problems" to move the files I did the same thing as I did not initially setup the cache when I spun up the system.

  • Upvote 1
Link to comment
7 hours ago, aqua said:

I plan on adding a cache drive later but not on the test build - is it easy to move dockers etc over to the cache drive later or do I need to set them up again? I assume there would be some setting where I can say where the data for them exists and I just change it, correct? 

As long as you don't use any path that specifies a specific disk, and instead only use paths that refer to user shares, then you are most of the way to getting things setup to run on cache. There are a few steps you would need to perform to get the files actually moved to cache, but you shouldn't have to change any paths used by individual dockers.

  • Upvote 1
Link to comment
12 hours ago, trurl said:

As long as you don't use any path that specifies a specific disk, and instead only use paths that refer to user shares, then you are most of the way to getting things setup to run on cache. There are a few steps you would need to perform to get the files actually moved to cache, but you shouldn't have to change any paths used by individual dockers.

Installed last night. I won't be specifying specific disks. Can you tell me what the steps would be to move to cache or point me to somewhere this has been described already? Is it just changing it to use cache or do I need to copy folders over etc?

Link to comment

I'll give a brief outline here and if you need more help you can post your diagnostics so we can better see exactly how you have things configured and can elaborate on each step.

 

Install cache.

Stop Docker and VM Services (Mover won't move open files).

Run Mover to get the cache-prefer shares system, domains, appdata moved to cache.

Start Docker and VM Services.

 

Link to comment

OK, thanks. I'll need to double check then that the dockers are set to cache-prefer. Not sure what the default is. 

Your instructions will then move the appdata paths to a cache drive and adjust paths as needed? And in docker setting it as cache-prefer will have the appdata for the docker in cache but not keep the downloads from sab kept as cache-prefer, right?

Link to comment
5 minutes ago, aqua said:

OK, thanks. I'll need to double check then that the dockers are set to cache-prefer. Not sure what the default is. 

Your instructions will then move the appdata paths to a cache drive and adjust paths as needed? And in docker setting it as cache-prefer will have the appdata for the docker in cache but not keep the downloads from sab kept as cache-prefer, right?

The default for those shares should already be cache Prefer.    Your dockers path should currently be set to /mnt/user type paths, and if so the move is completely transparent as cache is included in User Shares.    The main thing is not have any shares you do NOT want on the cache set to cache Prefer as this would cause mover to attempt to move their contents to the cache.    If you have any shares that you initially want written to the cache and then transparently moved to array disks when mover runs overnight set them to cache Yes.   It is not uncommon for people to get confused by the difference between cache-Prefer and cache-Yes (although the GUI Help does give a good explanation of the differences if you make use of it).

  • Upvote 1
Link to comment

User shares are just the aggregate of all top level folders on cache and array with the same name. If you specify user share paths then there will be no need to adjust paths, as I already mentioned.

 

Mover moves files and folders of cache-prefer user shares from array to cache. By default, the system, domains, and appdata shares should already be cache-prefer. If you set these up before having cache, they will be on the array, but can be moved to cache as long as they aren't open.

 

14 minutes ago, aqua said:

OK, thanks. I'll need to double check then that the dockers are set to cache-prefer. Not sure what the default is. 

Your instructions will then move the appdata paths to a cache drive and adjust paths as needed? And in docker setting it as cache-prefer will have the appdata for the docker in cache but not keep the downloads from sab kept as cache-prefer, right?

Don't really know how to answer any of that since it doesn't really correspond to how anything works.

 

Each user share has a setting for whether and how it uses cache. Dockers themselves don't really know anything about cache. They just use whatever paths you give them in the volume mappings.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.