Sorry for the long description but I wanted to make sure that I provided a detailed breakdown 🙂

 

--

 

I've set up a dedicated unraid server (Starter license, 6.12.13) to serve files, photos and other important data to the household.

 

Disk layout is dual parity (3+4TB drive), three (xfs) data drives (3TB each)  and one SSD (250GB) cache drive (btrfs)

 

I've figured out that I can rearrange data so I need only two data drives. That brings me down to 5 out of 6 disks allocated. I'd like to use the now free slot to add an extra SSD to the cache pool - and go from 1x250GB to 2x500GB in RAID1, to get the added robustness for apps as well.

 

I feel pretty prepared but have a few questions I'd like some input on. I've added them in my work step descriptions in red.

 

All of this would involve a Shrink array part and an Expand cache pool part, for which I have detailed the as I see them.

 

Shrink array

1. Consolidate data on two drives (I'm thinking of using unBalance for this)
2. Shrink array following either
   1. Method 1: "Remove Drives Then Rebuild Parity" (https://docs.unraid.net/legacy/FAQ/shrink-array/#the-remove-drives-then-rebuild-parity-method) which violates parity that must rebuild; or
   2. Method 2: "Clear Drive Then Remove Drive" method (https://docs.unraid.net/legacy/FAQ/shrink-array/#the-clear-drive-then-remove-drive-method) which maintains parity but has notes about being not fully tested - and has several more steps

 

Questions:

• Is this the best way to go about shrinking the array?
• Which is the better method of the two listed? Should I favour Method 2 (maintaining parity) over Method 1 (lower complexity, but rebuild of parity)

 

Expand cache pool

Add 500GB SSD (info from FAQ for unRAID v6)

1. Shut down server, add one 500GB SSD
2. Start server, add 500GB SSD to cache pool
3. Start array, wait for pool to balance

Replace 250GB SSD with 500GB SSD (info from FAQ for unRAID v6)

1. Shut down server, replace 250GB SSD with 500GB SSD
2. Start server, replace missing entry in cache pool with 500GB SSD
3. Start array, wait for pool to balance
4. May need to stop/start array as new device is larger

 

 

Questions:

• Is this correct, overly complicated or is there something I've forgotten about?

 

 

Preparation already made

• Both 500GB SSDs have been precleared
• Using the AppData Backup plugin, I have
  • a backup of my flash drive to a backup folder on the array
  • a backup of my dockers and settings to a backup folder on the array
• I have full backup of all my data shares on a cloud drive
• I have a full backup of all array shares (including aforementioned backup folder) on an external USB disk

 

Thanks in advance for thoughts, comments and suggestions.

 

 

Edited November 13, 20241 yr by t33j4y

in truth, I'm not sure how to shrink the array... I have done so in the past on older unraid 5... mby boot to a live ubuntu os and use disk to shrink a partition... other data on forum
https://docs.unraid.net/legacy/FAQ/shrink-array/
 

 

Your plan is well thought out and covers the essential steps for both shrinking the array and expanding the cache pool. I’ll walk through your questions and provide a few tips to help streamline the process and ensure a safe transition.

 

Part 1: Shrink Array

Choosing the Shrink Method

Both methods you listed are valid, but there are pros and cons to each:

 

Method 1 (Remove Drives Then Rebuild Parity):

This is simpler in terms of steps and will likely be faster because it avoids the need to zero out the drive.

However, since it requires a complete parity rebuild, there is a brief period where parity protection is lost, leaving your array vulnerable until the rebuild completes.

 

Method 2 (Clear Drive Then Remove Drive):

This method maintains parity throughout the process by zeroing out the drive, allowing you to safely remove it without a parity rebuild.

Although it has more steps and may take a bit longer, it offers more data protection since parity is preserved throughout the process.

 

Recommendation: Method 2 is generally safer, especially if you’re concerned about data integrity and have the patience to go through the extra steps. However, if you’re comfortable with a temporary parity loss and want a simpler process, Method 1 is a viable choice.

 

Steps for Shrinking the Array

Here’s a refined approach based on your steps:

Use unBalance to migrate data from the drive you’re planning to remove. Verify the data has been fully transferred by spot-checking a few folders.

Run Method 2 if you want to maintain parity. Otherwise, go with Method 1 for a quicker process.

Final Check: After shrinking, verify the array is operational with the remaining drives.

 

Part 2: Expanding the Cache Pool

Your expansion plan looks mostly accurate, but let’s address some specifics to ensure it goes smoothly.

 

Steps to Expand the Cache Pool

Add the First 500GB SSD:

Shut down the server, insert the first 500GB SSD, and then boot up.

In UnRaid, add the new 500GB SSD to the cache pool. Since this is a Btrfs pool, it should automatically balance across both drives in a RAID1 configuration, providing redundancy.

Start the array and let the pool balance. This might take some time depending on the amount of data in the cache.

 

Replace the 250GB SSD with the Second 500GB SSD:

Shut down the server again, swap the 250GB SSD for the second 500GB SSD, and boot up.

In UnRaid, assign the new 500GB SSD to replace the missing slot in the cache pool.

Start the array and allow the pool to balance again.

 

*Note: As you pointed out, you may need to stop and start the array for UnRaid to recognize the new SSD size properly. Keep an eye on the cache pool status during the balancing process.

 

Verifying the Cache Pool

After both SSDs are in place and the balancing is complete, double-check that the cache pool is now showing the correct RAID1 configuration and 500GB capacity. This can be done in Main > Cache Pool or by looking at the btrfs stats to confirm redundancy.

 

#########

 

Final Checks and Considerations

You’ve done an excellent job preparing, with comprehensive backups, pre-cleared SSDs, and data redundancy. Just a few final points:

Verify Backups: Ensure the AppData backup and the flash drive backup are recent and verified, as these will be essential in case of any issues during the migration.

Check Docker and VM Configurations: After completing the process, double-check Docker and VM configurations to ensure they’re utilizing the expanded cache pool correctly.

Monitor System Stability: Keep an eye on the system logs and overall server performance for a few days after the transition to catch any potential issues early.

These steps should ensure a smooth transition and improved redundancy in your UnRaid setup

Edited November 14, 20241 yr by bmartino1

23 hours ago, bmartino1 said:

in truth, I'm not sure how to shrink the array... I have done so in the past on older unraid 5... mby boot to a live ubuntu os and use disk to shrink a partition... other data on forum
https://docs.unraid.net/legacy/FAQ/shrink-array/
 

 

Your plan is well thought out and covers the essential steps for both shrinking the array and expanding the cache pool. I’ll walk through your questions and provide a few tips to help streamline the process and ensure a safe transition.

 

Part 1: Shrink Array

Choosing the Shrink Method

Both methods you listed are valid, but there are pros and cons to each:

 

Method 1 (Remove Drives Then Rebuild Parity):

This is simpler in terms of steps and will likely be faster because it avoids the need to zero out the drive.

However, since it requires a complete parity rebuild, there is a brief period where parity protection is lost, leaving your array vulnerable until the rebuild completes.

 

Method 2 (Clear Drive Then Remove Drive):

This method maintains parity throughout the process by zeroing out the drive, allowing you to safely remove it without a parity rebuild.

Although it has more steps and may take a bit longer, it offers more data protection since parity is preserved throughout the process.

 

Recommendation: Method 2 is generally safer, especially if you’re concerned about data integrity and have the patience to go through the extra steps. However, if you’re comfortable with a temporary parity loss and want a simpler process, Method 1 is a viable choice.

 

Steps for Shrinking the Array

Here’s a refined approach based on your steps:

Use unBalance to migrate data from the drive you’re planning to remove. Verify the data has been fully transferred by spot-checking a few folders.

Run Method 2 if you want to maintain parity. Otherwise, go with Method 1 for a quicker process.

Final Check: After shrinking, verify the array is operational with the remaining drives.

 

Part 2: Expanding the Cache Pool

Your expansion plan looks mostly accurate, but let’s address some specifics to ensure it goes smoothly.

 

Steps to Expand the Cache Pool

Add the First 500GB SSD:

Shut down the server, insert the first 500GB SSD, and then boot up.

In UnRaid, add the new 500GB SSD to the cache pool. Since this is a Btrfs pool, it should automatically balance across both drives in a RAID1 configuration, providing redundancy.

Start the array and let the pool balance. This might take some time depending on the amount of data in the cache.

 

Replace the 250GB SSD with the Second 500GB SSD:

Shut down the server again, swap the 250GB SSD for the second 500GB SSD, and boot up.

In UnRaid, assign the new 500GB SSD to replace the missing slot in the cache pool.

Start the array and allow the pool to balance again.

 

*Note: As you pointed out, you may need to stop and start the array for UnRaid to recognize the new SSD size properly. Keep an eye on the cache pool status during the balancing process.

 

Verifying the Cache Pool

After both SSDs are in place and the balancing is complete, double-check that the cache pool is now showing the correct RAID1 configuration and 500GB capacity. This can be done in Main > Cache Pool or by looking at the btrfs stats to confirm redundancy.

 

#########

 

Final Checks and Considerations

You’ve done an excellent job preparing, with comprehensive backups, pre-cleared SSDs, and data redundancy. Just a few final points:

Verify Backups: Ensure the AppData backup and the flash drive backup are recent and verified, as these will be essential in case of any issues during the migration.

Check Docker and VM Configurations: After completing the process, double-check Docker and VM configurations to ensure they’re utilizing the expanded cache pool correctly.

Monitor System Stability: Keep an eye on the system logs and overall server performance for a few days after the transition to catch any potential issues early.

These steps should ensure a smooth transition and improved redundancy in your UnRaid setup

 

Thank you very much for your detailed and good comments - they are much appreciated and will help tighten up the process! I will add your suggestions to my playbook and get ready for digging in this weekend!

I ran the 'clear an array drive' but I am really unsure if it has completed as I read it would take a long time to zero out the drive - and iif it has indeed completed, it did not take very long time. I did reformat the drive first.

 

This is what is says right now:

 

 

Looking at the main screen, the write count is stopped at 358.395 and is just sitting there. Unsure whether it's still running as the instructions state: "While the script is running, the Main screen may show invalid numbers for the drive, ignore them."

 

 

So am I seeing invalid numbers or has it really completed? Do I click done, stop the array and proceed as per the instructions to do New Config and so on?

 

 

 

Edited November 18, 20241 yr by t33j4y

the goruping of 1 and total dat on the disk must have been small.

for a 3 tb with lets say less than 500 GB of strage that seem correct.

8 hours ago, bmartino1 said:

the goruping of 1 and total dat on the disk must have been small.

for a 3 tb with lets say less than 500 GB of strage that seem correct.

I'd assume that zeroing out a 3TB drive takes the same time, regardless of what level of utilization it was before (even zeros get zeroed)?

 

Everything needs to be forcefully flipped to a zero, right?

 

Edited November 18, 20241 yr by t33j4y

3 minutes ago, t33j4y said:

Everything needs to be forcefully flipped to a zero, right?

Yes - existing usage is therefore irrelevant.

1 hour ago, itimpi said:

Yes - existing usage is therefore irrelevant.

Ok 🙂 So where does that leave me in terms of deciding whether zeroing of my 3TB was either extremely fast, still ongoing or something third?

 

 

33 minutes ago, t33j4y said:

Ok 🙂 So where does that leave me in terms of deciding whether zeroing of my 3TB was either extremely fast, still ongoing or something third?

 

 

It did not work properly as it says a little over 8MB was written whereas a full clear would be 3TB.  Providing diagnostics might allow for more informed feedback.

1 hour ago, itimpi said:

It did not work properly as it says a little over 8MB was written whereas a full clear would be 3TB.  Providing diagnostics might allow for more informed feedback.

Thanks - I have attached diagnostics - hopefully that can reveal something.

 

hesiod-diagnostics-20241118-1553.zip

Cannot see any error, but

 

Nov 18 01:43:50 Hesiod clear_array_drive: Clear an unRAID array data drive  v1.4
Nov 18 01:43:50 Hesiod clear_array_drive: Unmounting Disk 3  (command: umount /mnt/disk3 ) ...
Nov 18 01:43:50 Hesiod kernel: XFS (md3p1): Unmounting Filesystem
Nov 18 01:43:50 Hesiod clear_array_drive: Clearing Disk 3  (command: dd bs=1M if=/dev/zero of=/dev/md3  ) ...
Nov 18 01:43:50 Hesiod clear_array_drive: Clearing Disk 3 is complete

Shows it completed almost immediately which cannot be right.

1 hour ago, itimpi said:

Cannot see any error, but

 

Nov 18 01:43:50 Hesiod clear_array_drive: Clear an unRAID array data drive  v1.4
Nov 18 01:43:50 Hesiod clear_array_drive: Unmounting Disk 3  (command: umount /mnt/disk3 ) ...
Nov 18 01:43:50 Hesiod kernel: XFS (md3p1): Unmounting Filesystem
Nov 18 01:43:50 Hesiod clear_array_drive: Clearing Disk 3  (command: dd bs=1M if=/dev/zero of=/dev/md3  ) ...
Nov 18 01:43:50 Hesiod clear_array_drive: Clearing Disk 3 is complete

Shows it completed almost immediately which cannot be right.

Hmm... so do I:

 

A. Try running the script again?

B. Ditch method 2 and go to method 1 (which means rebuild parity) and jump in at step 3?

 

1. Make sure that the drive or drives you are removing have been removed from any inclusions or exclusions for all shares, including in the global share settings. Shares should be changed from the default of "All" to "Include". This include list should contain only the drives that will be retained.
2. Make sure you have a copy of your array assignments, especially the parity drive. You may need this list if the "Retain current configuration" option doesn't work correctly
3. Stop the array (if it is started)
4. Go to Tools then New Config
5. Click on the Retain current configuration box (says None at first), click on the box for All, then click on close
6. Click on the box for Yes I want to do this, then click Apply then Done
7. Return to the Main page, and check all assignments. If any are missing, correct them. Unassign the drive(s) you are removing. Double check all of the assignments, especially the parity drive(s)!
8. Do not click the check box for Parity is already valid; make sure it is NOT checked; parity is not valid now and won't be until the parity build completes
9. Start the array to commit the changes; system is usable now, but it will take a long time rebuilding parity

a empty disk done't have data written and is already in 0 wrtten mode as how its read..

I wnat to know how much space was written to it. if no data, the still seems resaonable. as only the text chip on the harddrvie (frogeting teh parts fo spinng rust as i don't mess with them much. Preclear has awalys been a trouble spot for me. 

If realyy that concenerd boot to ubuntu live and use disk to check system and clear the disk with the same dd command...
 

4 hours ago, bmartino1 said:

a empty disk done't have data written and is already in 0 wrtten mode as how its read..

I wnat to know how much space was written to it. if no data, the still seems resaonable. as only the text chip on the harddrvie (frogeting teh parts fo spinng rust as i don't mess with them much. Preclear has awalys been a trouble spot for me. 

If realyy that concenerd boot to ubuntu live and use disk to check system and clear the disk with the same dd command...
 

 

Unsure what you mean by "I wnat to know how much space was written to it." - if you mean as a result of running the script:

 

 

I'm not concerned per se, I just want to make the right choice to proceed and not botch things and make more work for myself than necessary :-)

before the clear.

that the output of what you atemted to clear i what to kown if the disk had any data on it and if so how much sp[ace out of the 3TB... This is where teh 1 spaced would be fliped... of it was a failry new drive with no data then yes this is correct...

@bmartino1

Before the clear, the drive had approx 500GB on it, which was written over the last couple of months after a preclear. Data was moved away, the drive was reformatted (stop array, swap to XFS encrypted, start array and wait for format. Then the same, swapping back to XFS) Then created the 'clear-me' folder and that was it.

thx. how did you do the reformat? all within unraid?

then no a preclear didn't finish nor run properly.

https://askubuntu.com/questions/812934/how-much-time-does-it-take-to-zero-out-hard-disk-of-500gb

18 minutes ago, bmartino1 said:

thx. how did you do the reformat? all within unraid?

then no a preclear didn't finish nor run properly.

https://askubuntu.com/questions/812934/how-much-time-does-it-take-to-zero-out-hard-disk-of-500gb

Yes, everything was done within unraid.

as long as the disk and array is doing what you expect from it, i wouldn't worry about it.

Wanted to wrap this up, so here goes.

 

1. I never managed to get the script for method 2 to complete. So while it seemed a good way, either I was doing something wrong that made the script complete prematurely and without any errors in log or it is not mature enough for general use?

2. After considering that I had enough backup and safety net, I ended up doing what I stated in option B (see quote below) and then weathered the parity rebuild time and the (slightly) higher exposure to risk.

 

Everything went well 🙂

 

On 11/18/2024 at 6:34 PM, t33j4y said:

Hmm... so do I:

 

A. Try running the script again?

B. Ditch method 2 and go to method 1 (which means rebuild parity) and jump in at step 3?

 

1. Make sure that the drive or drives you are removing have been removed from any inclusions or exclusions for all shares, including in the global share settings. Shares should be changed from the default of "All" to "Include". This include list should contain only the drives that will be retained.
2. Make sure you have a copy of your array assignments, especially the parity drive. You may need this list if the "Retain current configuration" option doesn't work correctly
3. Stop the array (if it is started)
4. Go to Tools then New Config
5. Click on the Retain current configuration box (says None at first), click on the box for All, then click on close
6. Click on the box for Yes I want to do this, then click Apply then Done
7. Return to the Main page, and check all assignments. If any are missing, correct them. Unassign the drive(s) you are removing. Double check all of the assignments, especially the parity drive(s)!
8. Do not click the check box for Parity is already valid; make sure it is NOT checked; parity is not valid now and won't be until the parity build completes
9. Start the array to commit the changes; system is usable now, but it will take a long time rebuilding parity

 

Edited December 9, 20241 yr by t33j4y