Appdata on Cache SSD or unassigned device SSD


Recommended Posts

My unraid server(used mainly for plex) originally had a 128gb SSD( not amazing, old one from 2013) and i just recently got a 970 evo plus 1TB NVMe. I need some advice as to what would be the best configuration. Do i use the Evo as my cache drive and have the appdata, system, and downloads share all on the cache drive. Do i use the Evonas that but instead use the 128gb as an only plex appdata UD drive(if thats even big enough). Do i keep the 128gb as the cache and use the Evo as an UD with appdata and whatever else. I’m trying to get the most performance out of the system so any help would be appreciated. Thanks for anyone who helps! Feel free to ask me more questions as i’m still new to the unraid scene and don’t know much so my question might be difficult to understand.

 

 

Sent from my iPhone using Tapatalk

Link to comment
  • 4 weeks later...
On 11/22/2020 at 9:32 PM, jonathanm said:

The 6.9 beta includes native support for multiple cache pools, which is the preferred way going forward.

 

Hi - I have this same question. Should I not be using Unassigned Devices? I currently have a 1TB NVMe SSD and a separate 500GB 2.5" SSD. I'm confused how I should have both of my SSDs setup to optimize for my use case. Should I be setting each as a "cache pool" and then specify Plex/VMs/appdata/Docker containers to be installed only on the NVMe "cache pool" and make sure this cache pool isn't also set to cache files on the array, while the 2.5 SSD "cache pool" is set as a traditional cache under each of the array settings?

  • 1TB SK Hynix Gold P31 NVMe SSD: Plex metadata with thumbnails + 20-30 docker containers + the associated appdata + 1-2 VMs sitting on the NVMe drive
  • 500GB Samsung EVO 850 2.5" SSD: used as a traditional "cache" drive, where all my downloads / torrents / scratch files sit, and files are written here before the the mover moves them onto my 8-disk HDD array (using without parity)
Link to comment

To prevent misunderstanding, it is best to make the deliberate effort to change the way we are thinking and talking about pools.

 

Up to 6.8.3 there was only one pool and the named was fixed : cache. Even if the caching functionality was not use, and/or it had other use case.

 

One of the thing that can help make it clear for you in your use case is to chose the names of the pools so it is clearly understandable for you. And maybe not use the name cache at all.

 

One thing that can help understand is to go back the configuration and the possibilities.

For each Share, you can selection a pool association (pool A, pool B, etc.) and the expected behavior (No / Yes / Prefer / Only).

I do think that the Option names could be changed in order not to induce this confusion on the Share page.

 

From your post, you want a pool for your static data (appdata, etc) and one for temporary files (torrents, etc.)

 

My advice, create two pools:

  • the first named static (or whatever name makes the most sense to you) with your 1TB
  • the second named scratch (or whatever name makes the most sense to you) with your 500GB

Then, on a share by share basis, decide what pool to associate and the way the pool shall work with this share. Some examples to help you:

  • appdata share set to static pool and Use cache pool set to Only (potentially to Prefer). This way it stays there.
  • torrent share set to scratch pool and Use cache pool set to Prefer (or Only). This way the downloads and temporary files stay on scratch unless this gets too large. When the download and sharing phase is done, the files can be moved to the appropriate Media share (below).
  • Media share set to scratch pool and Use cache pool set to Yes. This way, the files stay on the share until the Mover is scheduled.

 

I hope this is clearer. :/

If not, ask for details.

If you need help to get from your actual setup to something like this and you are not sure how, do not hesitate to ask.

  • Like 2
  • Upvote 1
Link to comment
  • 2 weeks later...
On 12/21/2020 at 10:35 AM, ChatNoir said:

To prevent misunderstanding, it is best to make the deliberate effort to change the way we are thinking and talking about pools.

 

Up to 6.8.3 there was only one pool and the named was fixed : cache. Even if the caching functionality was not use, and/or it had other use case.

 

One of the thing that can help make it clear for you in you use case is to chose the names of the pools so it is clearly understandable for you. And maybe not use the name cache at all.

 

One thing that can help understand is to go back the configuration and the possibilities.

For each Share, you can selection a pool association (pool A, pool B, etc.) and the expected behavior (No / Yes / Prefer / Only).

I do think that the Option names could be changed in order not to induce this confusion on the Share page.

 

From your post, you want a pool for your static data (appdata, etc) and one for temporary files (torrents, etc.)

 

My advice, create two pools:

  • the first named static (or whatever name makes the most sense to you) with your 1TB
  • the second named scratch (or whatever name makes the most sense to you) with your 500GB

Then, on a share by share basis, decide what pool to associate and the way the pool shall work with this share. Some examples to help you:

  • appdata share set to static pool and Use cache pool set to Only (potentially to Prefer). This way it stays there.
  • torrent share set to scratch pool and Use cache pool set to Prefer (or Only). This way the downloads and temporary files stay on scratch unless this gets too large. When the download and sharing phase is done, the files can be moved to the appropriate Media share (below).
  • Media share set to scratch pool and Use cache pool set to Yes. This way, the files stay on the share until the Mover is scheduled.

 

I hope this is clearer. :/

If not, ask for details.

If you need help to get from your actual setup to something like this and you are not sure how, do not hesitate to ask.

This really helped my thnking! Thanks! :)

  • Like 1
Link to comment
  • 2 years later...
On 12/21/2020 at 5:35 AM, ChatNoir said:

To prevent misunderstanding, it is best to make the deliberate effort to change the way we are thinking and talking about pools.

 

Up to 6.8.3 there was only one pool and the named was fixed : cache. Even if the caching functionality was not use, and/or it had other use case.

 

One of the thing that can help make it clear for you in your use case is to chose the names of the pools so it is clearly understandable for you. And maybe not use the name cache at all.

 

One thing that can help understand is to go back the configuration and the possibilities.

For each Share, you can selection a pool association (pool A, pool B, etc.) and the expected behavior (No / Yes / Prefer / Only).

I do think that the Option names could be changed in order not to induce this confusion on the Share page.

 

From your post, you want a pool for your static data (appdata, etc) and one for temporary files (torrents, etc.)

 

My advice, create two pools:

  • the first named static (or whatever name makes the most sense to you) with your 1TB
  • the second named scratch (or whatever name makes the most sense to you) with your 500GB

Then, on a share by share basis, decide what pool to associate and the way the pool shall work with this share. Some examples to help you:

  • appdata share set to static pool and Use cache pool set to Only (potentially to Prefer). This way it stays there.
  • torrent share set to scratch pool and Use cache pool set to Prefer (or Only). This way the downloads and temporary files stay on scratch unless this gets too large. When the download and sharing phase is done, the files can be moved to the appropriate Media share (below).
  • Media share set to scratch pool and Use cache pool set to Yes. This way, the files stay on the share until the Mover is scheduled.

 

I hope this is clearer. :/

If not, ask for details.

If you need help to get from your actual setup to something like this and you are not sure how, do not hesitate to ask.


When you say appdata share set to static pool and use cache pool set to ONLY. Are you saying the appdata remains on the static pool? I am not sure i understand this fully. appdata is like your db no?

Link to comment
8 hours ago, max7 said:

When you say appdata share set to static pool and use cache pool set to ONLY. Are you saying the appdata remains on the static pool? I am not sure i understand this fully. appdata is like your db no?

Docker containers are split in two major elements :

  • the elements that can change (settings, DBs, etc.), that's on your appdata
  • and those that do not change, that's in the docker image

For performance reasons, it is generally better to have both on SSDs and so on a Pool. And they would stay on the Pool with the settings above.

 

Note that with 6.12, the wording and organisation of those settings in Shares has changed. While the ideas behind the choice are the same, the things are organized differently and might be easier to understand. (the Exclusive access part is optional)

 

image.thumb.png.ee852eee1be21fa8a603b7282f32c28b.png

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.