As of unraid 6.12, you can now get the same effect by using "Exclusive shares". Exclusive shares mean that if the share is only set to use a single pool and no secondary storage, then unraid will automatically bypass the Fuse system. Using exclusive shares, you can continue to reference the /mnt/user/ path in your docker volumes, scripts, etc -- but you'll get a same performance benefit as if you reference the drive pool directly. The setting is found in 'Settings' -> 'Global Share Settings' if you want to apply it globally.
To follow up on this, I enabled this setting and it has caused my Win10 VM to constantly pause itself. Now I don't know why this is but if I revert this setting it doesn't do it. So clearly it is related to this Exclusive Shares option. My cache is configured as a pool of two BTRFS formatted NVME drives in mirrored raid (not hardware, through unraid). So this option may not be the silver bullet it appears to be.
@@poprin5194 you're sure there isn't another issue going on? The exclusive shares just create a symlink and bypass the fusion filesystem. This should be reliable
Thanks for this! Just starting to learn Unraid and been enjoying it so far. From what I understand, once I setup the "Exclusive Shares", I don't really need to change anything in the docker settings path as long as I'm pointing it to a share that is set to "Cache" only and the secondary set to none?
The fix described in the video involves optimizing the paths used by Docker containers to reduce IO wait and improve CPU efficiency in Unraid. Specifically: 1. Modify Docker Container Paths: - Change the file paths within Docker containers from the default "Mount/user" paths to directly target the cache drives. - For example, change "Mount/user/app/data" to "Mount/cache/app/data" for the application directory used by Docker containers. 2. Address Cache Drives Directly: - Recognize that each cache drive in your system, whether in the array or a cache pool, has its own individual addressable path. - By directing Docker containers to write directly to the cache drives, you can bypass unnecessary processing overhead caused by the Fuse file system. 3. Restart Docker Containers: - After making these path modifications, restart your Docker containers. - This change should result in a significant reduction in IO wait, leading to improved system performance and more efficient CPU usage in Unraid. By implementing these adjustments, you can enhance the performance of your Unraid server, especially when dealing with high levels of disk IO wait.
I am sorry to be "that guy who's not fun at parties", but this might actually be bad advice because it's not telling the whole truth - data protection. Data on your array is (most usually) protected by one or two parity drives. Data on your cache pools is not protected against a drive failure, especially if you don't use a mirrored cache pool. So if your cache drive dies, you lose all of the data on there: appdata, config files, and so on. It would have been great to explain this to your viewers, and propose mitigation options: appdata backup, etc.
That's a great point, thank you for pointing that out, even if it did kill the vibe at the party ;). I'll do an updated video here shortly with some suggestions.
While that is true. It is true if you go through FUSE or directly to the cache as he states. I have mine mirrored for protection. With the latest unRaid you can set up Zpools for your cache and have them redundant also. Space Invader did a good series on that.
Cache drives are going to be a thing of the past shortly anyway as their use is not much more than a bolted-on band-aid anyway and they're not remotely similar to the function of a real cache anyway. People who want performance and robustness are going to use ZFS pools, even if it comes with the downside of being the most inflexible deployment available.
This sounded very promising but turned out o not work for me. Some dockers worked fine but others didn't. Specifically my sabNZBd Docker container is the one I need to speed up the most and after implementing your fix I get permissions errors. unable to create file! Nothing I have tried will fix this.
i have to come back and say huge improvements that dose not show in cpu useage but in user use ability i mean huge mostly in my plex and nvr systems. im still dont understand the use of the forward of the cache download but my download cache is only 400gb so i have it as "yes" but ill try it for a few day and report back. thank you for something i had know idea i didnt know that i needed but wow.
That’s awesome to hear. For me I was pretty frustrated before figuring this out. Made a big difference in the overall usability. Glad you are seeing the same
now that zfs is baked in, no need to prefer cache for shares anymore since data writes are striped across your disks. just keep your appdata on cache assuming you've got a flash based disk and backup appdata daily to your pool/external drive/NFS or SMB share and you're covered. excellent video and explanation of how shares/disk allocation works
That's assuming you make a full ZFS pool and not just using ZFS formatted disks in the Unraid array. ZFS disks in the array still operate no differently than the array did before. And if you make a full ZFS pool, you are then bound by all of the limitations that come with running a ZFS array (having to have all disks in the pool spinning, no expansion without burning more disks to parity, all disks need to be identical, etc). There is no good reason to run a full ZFS pool for a Unraid media server.
@@brandonk1163 that's subjective of course, everyone's use case is a bit different. for me personally I won't miss parity checks on a 8x22TB drive pool/array and the extra performance/fault tolerance is something I use zfs over xfs/btrfs for the moment.
🎯 Key Takeaways for quick navigation: - [00:00] 📊 Understanding Disk IO Wait - Disk IO wait is the time CPU spends waiting for data from disks. - Identifying IO weight problems in Unraid. - Checking processor stats and IO weight in the Unraid dashboard. - [02:58] 💾 Unraid Caching Mechanisms - Exploring Unraid's caching layers: No, Yes, Prefer, and Only. - Understanding how data flows between cache drives and the disk array. - The impact of caching choices on system performance. - [06:12] 🐳 Docker Containers and File Paths - How Docker containers use file paths in Unraid. - The role of the Fuse file system in determining where files are written. - The importance of addressing cache drives directly to reduce IO wait. - [09:12] 🔄 Optimizing Docker Container Paths - Modifying Docker container paths to target cache drives. - Demonstrating changes in Plex and Sonarr configurations. - Benefits of reducing IO wait and improving CPU efficiency in Unraid.
Thanks. I knew it for plex, but never thought about changing all... LOL... THANKS. Sometimes its too easy. Why the devs dont make that default (or add that to the plugin fix common problems..?)
Heya! Thank you for this guide. I am confused though, how does hardlinking play into all of this? If you have let's say a movie downloaded to a cache drive, and your final movie directory goes through fusion, doesn't that make hardlinking impossible, making your downloads take twice the space?
Thank you for addressing the issue. Have a question: Will this setup exclude data protection if a drive failure occurs? SSD cache drive set-up won't compute and have the content written to the parity drive?
What I do not get, aren't the appdata files mandatory to run i.e. containers? if they're only persisted to cache and your cache - whyever - will die, all your appdata config files, etc. are lost, no?
I have lot of Apps already installed, If i Change the appdata cache to only or yes (it's in prefer now) Will I lost thoose App config that i already did on /mnt/user/appdata?. I dont want to Install thoose App and configure again. Thanks
As of unraid 6.12, you can now get the same effect by using "Exclusive shares". Exclusive shares mean that if the share is only set to use a single pool and no secondary storage, then unraid will automatically bypass the Fuse system.
Using exclusive shares, you can continue to reference the /mnt/user/ path in your docker volumes, scripts, etc -- but you'll get a same performance benefit as if you reference the drive pool directly. The setting is found in 'Settings' -> 'Global Share Settings' if you want to apply it globally.
This is why I always read the comments! Thanks for this!
To follow up on this, I enabled this setting and it has caused my Win10 VM to constantly pause itself. Now I don't know why this is but if I revert this setting it doesn't do it. So clearly it is related to this Exclusive Shares option. My cache is configured as a pool of two BTRFS formatted NVME drives in mirrored raid (not hardware, through unraid). So this option may not be the silver bullet it appears to be.
@@poprin5194 you're sure there isn't another issue going on? The exclusive shares just create a symlink and bypass the fusion filesystem. This should be reliable
@@poprin5194. Personally the Primary=Array and mover set to Array>Cache works fine for me, doesn’t seem to cause any issues with using fuse.
Thanks for this! Just starting to learn Unraid and been enjoying it so far. From what I understand, once I setup the "Exclusive Shares", I don't really need to change anything in the docker settings path as long as I'm pointing it to a share that is set to "Cache" only and the secondary set to none?
I've been using UnRaid for 6+ years now and never realised this! Thank you, hopefully will resolve some issues with IOWAIT spikes I've been getting.
The fix described in the video involves optimizing the paths used by Docker containers to reduce IO wait and improve CPU efficiency in Unraid. Specifically:
1. Modify Docker Container Paths:
- Change the file paths within Docker containers from the default "Mount/user" paths to directly target the cache drives.
- For example, change "Mount/user/app/data" to "Mount/cache/app/data" for the application directory used by Docker containers.
2. Address Cache Drives Directly:
- Recognize that each cache drive in your system, whether in the array or a cache pool, has its own individual addressable path.
- By directing Docker containers to write directly to the cache drives, you can bypass unnecessary processing overhead caused by the Fuse file system.
3. Restart Docker Containers:
- After making these path modifications, restart your Docker containers.
- This change should result in a significant reduction in IO wait, leading to improved system performance and more efficient CPU usage in Unraid.
By implementing these adjustments, you can enhance the performance of your Unraid server, especially when dealing with high levels of disk IO wait.
Just to be clear; ALL docker containers appdata should be written to /mnt/cache/appdata/appname, correct?
This reads like something written by ChatGPT.
That's exactly what it is@@MasterNeiXD
Jesus there are so many nuances to tweak on Unraid? thank you for this.
Soooo many, but… once you get it running well, it’s pretty solid.
I am sorry to be "that guy who's not fun at parties", but this might actually be bad advice because it's not telling the whole truth - data protection. Data on your array is (most usually) protected by one or two parity drives. Data on your cache pools is not protected against a drive failure, especially if you don't use a mirrored cache pool. So if your cache drive dies, you lose all of the data on there: appdata, config files, and so on. It would have been great to explain this to your viewers, and propose mitigation options: appdata backup, etc.
That's a great point, thank you for pointing that out, even if it did kill the vibe at the party ;). I'll do an updated video here shortly with some suggestions.
While that is true. It is true if you go through FUSE or directly to the cache as he states. I have mine mirrored for protection. With the latest unRaid you can set up Zpools for your cache and have them redundant also. Space Invader did a good series on that.
There is an app-data backup plugin makes it super easy to schedule app data backups.
@@jwnusser
A vm_Backup also!
Cache drives are going to be a thing of the past shortly anyway as their use is not much more than a bolted-on band-aid anyway and they're not remotely similar to the function of a real cache anyway. People who want performance and robustness are going to use ZFS pools, even if it comes with the downside of being the most inflexible deployment available.
thank you, super helpful, ive had unraid for a year and never kenw this!
Keep the unraid videos coming please great video and we’ll explained
You got it!
Please, Mehr unraid Videos.
Thank you
Great explanation and guide! Thank you so much, definitely worth a like and sub! 👌🏻
Awesome, thank you!
Perfect video, thanks. Subbed. :) more Unraid videos pls. You explain well.
More to come! Thanks for the sub
This sounded very promising but turned out o not work for me. Some dockers worked fine but others didn't. Specifically my sabNZBd Docker container is the one I need to speed up the most and after implementing your fix I get permissions errors. unable to create file! Nothing I have tried will fix this.
i have to come back and say huge improvements that dose not show in cpu useage but in user use ability i mean huge mostly in my plex and nvr systems. im still dont understand the use of the forward of the cache download but my download cache is only 400gb so i have it as "yes" but ill try it for a few day and report back. thank you for something i had know idea i didnt know that i needed but wow.
That’s awesome to hear. For me I was pretty frustrated before figuring this out. Made a big difference in the overall usability. Glad you are seeing the same
nevermind i get it your media share has no cache, you realy have changed my understanding of how cache works.
now that zfs is baked in, no need to prefer cache for shares anymore since data writes are striped across your disks. just keep your appdata on cache assuming you've got a flash based disk and backup appdata daily to your pool/external drive/NFS or SMB share and you're covered.
excellent video and explanation of how shares/disk allocation works
That's assuming you make a full ZFS pool and not just using ZFS formatted disks in the Unraid array. ZFS disks in the array still operate no differently than the array did before.
And if you make a full ZFS pool, you are then bound by all of the limitations that come with running a ZFS array (having to have all disks in the pool spinning, no expansion without burning more disks to parity, all disks need to be identical, etc).
There is no good reason to run a full ZFS pool for a Unraid media server.
@@brandonk1163 that's subjective of course, everyone's use case is a bit different. for me personally I won't miss parity checks on a 8x22TB drive pool/array and the extra performance/fault tolerance is something I use zfs over xfs/btrfs for the moment.
🎯 Key Takeaways for quick navigation:
- [00:00] 📊 Understanding Disk IO Wait
- Disk IO wait is the time CPU spends waiting for data from disks.
- Identifying IO weight problems in Unraid.
- Checking processor stats and IO weight in the Unraid dashboard.
- [02:58] 💾 Unraid Caching Mechanisms
- Exploring Unraid's caching layers: No, Yes, Prefer, and Only.
- Understanding how data flows between cache drives and the disk array.
- The impact of caching choices on system performance.
- [06:12] 🐳 Docker Containers and File Paths
- How Docker containers use file paths in Unraid.
- The role of the Fuse file system in determining where files are written.
- The importance of addressing cache drives directly to reduce IO wait.
- [09:12] 🔄 Optimizing Docker Container Paths
- Modifying Docker container paths to target cache drives.
- Demonstrating changes in Plex and Sonarr configurations.
- Benefits of reducing IO wait and improving CPU efficiency in Unraid.
thanks for this guide!
In 6.12 it doesn’t seem to spin up my array when I set the primary to the cache drive and have mover set to array to cache.
Why I don't have the option "Use Cache pool" ( In your case prefer )
Thanks. I knew it for plex, but never thought about changing all... LOL... THANKS. Sometimes its too easy. Why the devs dont make that default (or add that to the plugin fix common problems..?)
Having SMR drives (those 8TB) will give you trouble when they get fuller.
So far so good. I've had them running for a few years. I have replaced a couple in that time and when they die just go with 10TB drives.
Is this a picture of Basquait in the background? :)
Heya! Thank you for this guide. I am confused though, how does hardlinking play into all of this? If you have let's say a movie downloaded to a cache drive, and your final movie directory goes through fusion, doesn't that make hardlinking impossible, making your downloads take twice the space?
Thank you for addressing the issue. Have a question: Will this setup exclude data protection if a drive failure occurs? SSD cache drive set-up won't compute and have the content written to the parity drive?
You could lose data if the SSD fails and your files aren’t backed up to the array.
What I do not get, aren't the appdata files mandatory to run i.e. containers? if they're only persisted to cache and your cache - whyever - will die, all your appdata config files, etc. are lost, no?
Correct. For that I run regular backups
when i am doing this to an old server that has been running plex for awhile do i need to set plex up again once i change this?
With an existing installation of Plex, can I change the path from "user" to "cache" afterwards or should I have done that during the installation?
You can still change it after the fact.
Is this still the case for the latest version?
I have lot of Apps already installed, If i Change the appdata cache to only or yes (it's in prefer now) Will I lost thoose App config that i already did on /mnt/user/appdata?. I dont want to Install thoose App and configure again. Thanks
When you change the mount to only cache the mover will move the files from the array to the cache drive and it should all work as expected.
It's a little distracting with the audio on this video being completely out of sync.
guys he talks too much, TLDR: move docker app data path to point directly to the cache disk, rather than through the cache share
Can we trust a person who can't synchronize picture and sound to be taken seriously?
No we can't. His advice is as good as the synchronization.
your audio is off in this video....
About ½ way thru, I couldn't follow any longer, you talk a lot about serious stuff, but you never show things
He showed it at around 2/3 of the video
@@NhatLinhNguyen-ru5lf I will try at it again, thank you