Rick_

I've in the same situation, and just submitted a feature request to allow a straightforward, efficient, and safe procedure for upgrading the parity drive. Add your thoughts in the FR thread on whether you think it'd be useful, and how you'd change it.

TLDR I recommend a feature that allows a user to perform a "Parity Handover", which maintains synchronization between an existing parity drive to a new drive and allows the original parity drive to be removed. Use Case A user would like to replace an existing Parity 1 or Parity 2 drive with an equal or larger disk while minimizing down time and risk of data loss. They may want to replace a parity disk because it's getting close to end of life, or they may want to replace the disk with a larger-capacity disk, allowing them to repurpose the existing parity drive as a data drive (as described in this thread). Current Alternatives The majority of these are described in the documentation here. 1. Replace parity disk with new disk, start array in Normal mode, and let parity rebuild Straightforward, but if a data drive fails during the parity rebuild, the original parity disk will no longer be valid. Data recovery will likely be a headache. 2. Replace parity disk with new disk, start array in Maintenance mode, and let parity rebuild This keeps the parity drive valid since nothing is being written to the data disks, but requires extended downtime. 3. Use the Parity Swap procedure This option is intended for replacing a disabled/failed disk to expedite the process, and would only add more risk if used in this scenario (something highlighted in the documentation as well). 4. Add Parity 2 and remove Parity 1 This option seems to be best choice right now for maximizing uptime and protection. It involves assigning the new disk to Parity 2, letting Parity 2 be built, and then unassigning the original Parity disk. It's valid to only have Parity 2, but Parity 2 is more computationally expensive and the location of the disks matters, meaning they can't be moved around in the future without rebuilding parity. This same operation can be performed in the future to shift back to Parity 1. 5. Copy the parity drive and create a new config Undocumented to my knowledge. Manually sync the parity drive to a new, unassigned drive using a tool like dd, building a new config with the new drive as the parity drive, and attesting that parity is valid when rebuilding. I have NO IDEA if this would actually work. Conceptual Feature and Workflow While the array is stopped, in the Main tab of the Web GUI add a button below the existing parity disks that says "Configure Parity Handover". If both Parity 1 and Parity 2 are present, it will ask the user which disk they want to copy. Whichever one the user selects, a new slot will be added below the respective parity disk. For example, if I only have Parity 1 in my system, if I click "Configure Parity Handover", a new slot is added under Parity called "Parity Copy". I can then select the unassigned disk I want to copy parity to (limited to equal or greater-sized drives). If I click START, the array starts up as usual, but begins syncing the Parity disk and the Parity Copy disk. Optionally, you can provide the user an option to preclear the drive to stress-test it, but that should be able to be bypassed. During synchronization between the two drives, there should be some indicator (in the dashboard, Main tab, and/or bottom of the GUI) to show progress. During synchronization, the Parity Copy drive should show "Sync in Progress" to indicate that it's not safe to use the new drive as parity yet. Once the two drives are fully synced, the Parity Copy drive should show a "Synced" indicator with a button next to it that says "Complete Handover". If the user clicks "Complete Handover", a dialog should explain what is going to happen, which is: All services (Docker/VMs) will be shut down The array will enter maintenance mode (cannot write any more data to the data disks) The Parity Copy drive will be finalized (any remaining writes are completed to ensure it's in sync with the original Parity drive) The array is stopped, the old parity drive is removed from the Parity slot, the Parity Copy drive is assigned to the Parity slot with valid parity, and the array is started in Normal mode. Afterward, everything looks as it should. There was never a lack of data protection, and there was minimal downtime.

Hey did you ever figure out a solution for this? I'm considering the same setup.

Thanks! I was a little worried going that route since the description of the "New Config" tool only specifically refers to arrays, not pools, so I actually tried something a little different and was successful. Basically documenting it for my future self and anyone else who needs to do it as well: Shut down the system Physically installed a PCIe NVMe M.2 carrier card with an additional 1TB NVMe drive. Physically installed a 3.5" 2TB HDD Booted up the system In the Main tab, I left the array as it was (with the original NVMe drive) Created a new pool with the new NVMe drive using a btrfs file system Disabled Docker and VM Management in Settings Started the array Went to my Shares tab and set all the ones I want on the cache pool to Prefer: Docker (Docker being the name of my cache pool) This actually exposed a bug / UI issue with Unraid. From the main Shares page every one of my shares displayed Prefer: Cache. When clicking on the settings of a share, Use Cache Pool was set to Prefer and Select Cache Pool was set to Docker with the Apply button greyed out. I assumed that meant that I'm seeing the current settings, not realizing that "Cache" in "Prefer: Cache" was actually the name of a previous cache pool that doesn't exist anymore. This resulted in Mover not actually moving anything since the Cache pool didn't exist. I fixed this by changing the Use Cache Pool dropdown settings to No, then immediately changing it back to Prefer. The Apply button was then able to be clicked, saving the settings. In the Main tab I clicked the Move button. It took about 30 min to move 60 GB from the array NVMe to the cache NVMe. My next step is to add the 2TB HDD to the array, then remove the 1TB drive from the array and make it another cache pool for VMs. As a side note, I think they should rename the Use Cache Pool options... maybe something like: No --> Cache Unused, Write to Array Yes --> Write to Cache, Move to Array Prefer --> Write to Cache, Overflow to Array Only --> Write to Cache, Array Unused

I've seen that suggestion as well. How do you think I should go about "converting" my NVMe drive to a pool device, and is it an issue to have my docker/VMs running on a pool device and not the array itself? I'm still getting a feel for what the Unraid OS requires/expects.

First off, I apologize if anything I'm asking warrants a "RTFM" - I tried doing my due diligence by reading the manual and exploring the threads here, but before I start trying to experiment with my current setup I'd just like a sounding board. So my current hardware has support for one NVMe M.2 and one 2.5" or 3.5" disk. My plan was use Unraid as my Docker/VM manager while all of my media/data is hosted on my Synology DS920+. Since I didn't need a ton of space, I opted to forego using an HDD and just installed a single 1 TB NVMe drive. I set up my array on the single NVMe and installed Unassigned Devices in order to connect to the Synology NAS via SMB. Everything seemed to be working great for a while - I had a few docker containers installed (Plex and *arrs mostly) and a Home Assistant VM. But then things started getting a bit sluggish. The Plex/Radarr/Sonarr GUIs weren't responding as fast, and Plex didn't seem to want to serve up library information as quickly on any of my clients. After doing a bit of research it seems that using an SSD may not be recommended in the primary array. I believe I ignored this advice in the manual due to my lack of terminology experience, thinking that my single drive doesn't count as an "array". It also seems that since the SSD is in the array, trimming does not automatically occur, which could be causing some of the sluggishness I'm seeing (although most articles I read about trim point to write speeds, not read speeds). So I guess my questions are: 1. Is my current setup actually not advised? 2. If so, what changes should I make for my use case? My best guess is to somehow make my HDD (currently not installed) the array drive and make my NVMe a cache drive. Though I'm not sure how I should go about doing that in a way that minimizes the chance of me losing all of the data currently on the NVMe drive. I have backed up all of my applications, but I'd prefer not to go through the restoration process for each application if I can avoid it. Thanks in advance for any insight offered!