CozMedic

Hello, I'm looking for guidance on best practice when replacing >1 drives with 1 drive. If there is current/relevant documentation for my scenario and I am failing to find it, please link me to the correct document/guide. I've included diagnostics, but as a brief overview of my array as-is, I've also included this screenshot. Disks 1-4 are not only very old (average spinning-time of 7.5 years), but were all purchased at the same time, which leads me to believe that if one of them were to fail, there is a high likelihood of another failure during rebuild. I have a new 8TB drive (and another on the way) that I would like to replace the highlighted disks, 1 & 2 with. I cannot find a clear/definitive answer on the practice to do so properly. There's options (seemingly) ranging from taking one out at a time and letting parity rebuild, using Unbalanced to empty disks 1-2, using the New Config tool/utility, or possibly all or even none of these. I'd also be open to any opinionated ideas on if I should instead be simply adding a 2nd parity drive. None of the array's data is unreplaceable, just painful to do so. Many thanks in advance to any who are able to assist or have had experience performing similar upgrades. dd-nas-diagnostics-20251009-1005.zip

After following the documentation for modifying/replacing a pool, I had the same issue as @tojoski posted here (thanks for helping me realize what was going on!). My Docker share was set to primary cache (appdata) secondary array + move secondary -> primary. After giving up on mover, I moved the files to appdata manually (they were only on one disk anyway). My dockerimage share was set to cache/appdata primary with no secondary. Despite this, when I started the docker service and started reinstalling Docker apps from Community Applications, I've found that the dockerfile directory has been written only to disk5 of the array. Not even sure where to go from here. Any advice is appreciated. Thanks. dd-nas-diagnostics-20250110-1705.zip

Okay, so there's no 'trick' to getting it to write to the same storage (array) other than either setting my share to array only temporarily (either literally or through free space min), or using scheduling/limits within the apps like Tdarr or Unmanic themselves? I'm cool with that, I honestly thought I was just missing some glaring component. Thanks,

Hi Everyone, I've come across an issue I can't seem to solve on my own, and I haven't been able to find a clear solution online. I'm guessing there are others out there doing what I'm trying to achieve, and I'm hoping one of you could point me in the right direction. Here's the situation: I'm using either Unmanic, Tdarr or similar to add streams to my media files for enhanced compatibility. My server configuration includes two cache pools - one dedicated solely for Docker, and a 1TB SSD for things like downloads. The latter regularly moves its data onto the array each day. Now, the hiccup comes when I transcode, say, my whole movie library. Every newly transcoded file gets treated as a fresh download and lands back onto the SSD cache pool. This practice quickly saturates my SSD to its brink and causes subsequent issues. My question is this: Is this issue a result of some misconfiguration on my server? Or, is there a specific technique that will let these transcoded files stay on the array instead of the SSD? I'm assuming there's a way to manage the file placement post-transcoding, but I'm not quite sure how. Any help or suggestions would be greatly appreciated!

In an interesting find from when I set this up long ago, I found that my Docker image directory was pointing at "/mnt/cache/dockerimage/" instead of the "/mnt/user/dockerimage" share that exists. I'm not really sure if there are any consequences of this, or if it could even potentially be the cause of the drive locking up? In any case, I suppose the safest move is just setting it to a user share on "Appdata"/sdg instead of hoping setting it to the cache share would fix it...

UNRAID: 6.11.5 Hi friends, After some time my sketchy NVMe drive has failed and occasionally after running fine it will spew out Btrfs read-only errors, soft-locking the server until a full power cycle. The only thing I have on this drive/pool is my dockerimage in file/folder format. I have another pool with a single SATA m.2 SSD, also Btrfs, that stores my Docker Appdata folders. I don't think it would really be worth replacing this 512GB NVMe drive, assuming container performance will likely be similar on a SATA drive. Since the NVMe drive is seemingly normal until it inevitably locks up, should I, & what would be the proper way to move the dockerimage files to the SATA drive/pool?