kevindckr

I've ran an Unraid install on my old desktop hardware for ~2 years now and I love it. I initially used it to store data, but overtime bloated it with VMs/dockers. It's at the point now I'd like to have a separate machine with more compute to run these applications. I recently purchased a R730 which I plan to offload the applications onto and use the original Unraid machine for almost solely data storage. With that said, I would like to use an all SSD array on the R730 to keep whatever I run on it, "fast". I've known for a long time ever since I first started research Unraid SSDs ""cannot"" be used in the storage pool(s) and only as cache drives. I've also read 10's of posts that seem to kind of contradict that. I really can't find a clear answer that outlines when and if they are used what you are giving up, how to do it "the best", etc. Just little tidbits of information here and there that don't always match up. Provided I've seen moderator level members mention they've built all SSD machines for clients and themselves, I have to assume there is some reasonable way to do this. So the best I can tell (from limetech's response) is that when I select a drive I need to check its TRIM command type if its "Deterministic read zeros after TRIM" (DZ_TRIM) then that's the best outcome, "Deterministic read data after TRIM" (DX_TRIM) then that's "ok", and otherwise the drive probably shouldn't be used. Further, and I doubt this makes sense, I think I would just stay away from the SSDs listed as having some issue on the wikipedia TRIM page. What else can I do prior to actually setting up the array to ensure the SSDs I purchase are "good to use"? I've also seen some interesting solutions where users have no parity drive in the pool which somehow makes the situation better. How would this make the issue better? I've also seen solutions where, from what I can tell, users have a small HDD based storage pool and then utilize a large SSD cache pool and just run all the applications from there. Is there a good post or documentation on how to implement such a solution? And just overall, is there a Limetech specific page/documentation outlining any of this? If and when SSDs can be used as storage?

I did not have these parameters set, only the "extra" Port variables. After setting these it seems to be working better.. Though, what is the difference between adding the ports to VPN_INPUT_PORTS versus VPN_OUTPUT_PORTS. I see that you have 9117 (Jackett WebUI) as an input port but not output, but you also have 8686 (lidarr WebUI) as an output but not input. Why the difference for a WebUI port?

XPost from General Support I have followed Spaceinvader One's video describing how to route the network traffic of one container through another on my Unraid 6.9.1 installation. Specifically, I have routed my binhex-jackett container traffic through my binhex-delugevpn network. To do so I first edited the jackett setup Network type from "Bridge" to "None" Added Extra Parameters: '--net:container:binhex-deluge' Then edited the delugevpn setup Added new port utilizing jacket's (9117, 9117, TCP) Utilizing Spaceinvader One's trick to view the container's IP with `curl ifconfig.io` I can confirm that both containers share the same IP address. I can also view the logs of each container and both are running normally (based on what I have viewed in the log outputs before). I have also performed the same steps to route another container's, netdata, traffic through the delugevpn container to see if it is just an issue with jackett. I can also confirm that it shares the same IP address and the logs "look fine". Though for either container if I navigate to my server's IP address with the specific port for a given routed container, the WebUI still does not load. Interestingly. While the Web UI for jackett does not load, after it has failed it seems to have resolved to the '/UI/Dashboard' Though, I have visited the Web UI prior to implementing these changes, so I assume that is just cached in my browser... But, this does not happen when attempting to navigate to netdata's address. My only other guess is that I need to edit delugevpn's "Connection Manager" to allow for a new/another connection from the containers?.. I have tried a few seemingly logical connection settings to no avail. Potentially, should I disable 'STRICT_PORT_FORWARDING' in the container setup? I assume this is related to the IP tables of the container and does not have much to do with the described situation though..

I have followed Spaceinvader One's video describing how to route the network traffic of one container through another on my Unraid 6.9.1 installation. Specifically, I have routed my binhex-jackett container traffic through my binhex-delugevpn network. To do so I first edited the jackett setup Network type from "Bridge" to "None" Added Extra Parameters: '--net:container:binhex-deluge' Then edited the delugevpn setup Added new port utilizing jacket's (9117, 9117, TCP) Utilizing Spaceinvader One's trick to view the container's IP with `curl ifconfig.io` I can confirm that both containers share the same IP address. I can also view the logs of each container and both are running normally (based on what I have viewed in the log outputs before). I have also performed the same steps to route another container's, netdata, traffic through the delugevpn container to see if it is just an issue with jackett. I can also confirm that it shares the same IP address and the logs "look fine". Though for either container if I navigate to my server's IP address with the specific port for a given routed container, the WebUI still does not load. Interestingly. While the Web UI for jackett does not load, after it has failed it seems to have resolved to the '/UI/Dashboard' Though, I have visited the Web UI prior to implementing these changes, so I assume that is just cached in my browser... But, this does not happen when attempting to navigate to netdata's address. My only other guess is that I need to edit delugevpn's "Connection Manager" to allow for a new/another connection from the containers?.. I have tried a few seemingly logical connection settings to no avail.