I've read through the wiki and can't find this topic.  I'd like to convert an existing Data drive to a Cache drive to increase write speeds.  I'm on 4.4.2 Pro.  What's the proper procedure?

I've read through the wiki and can't find this topic.  I'd like to convert an existing Data drive to a Cache drive to increase write speeds.  I'm on 4.4.2 Pro.  What's the proper procedure?

To make it easier on you, you should probably delete any files from the data drive before you un-assign the data drive, otherwise they will be there when you assign it as a cache drive and subsequently moved to the data drives when the cache-mover script first runs.

 

If you are removing a disk from the protected array, and not replacing it, you must first un-assign it on the devices page and then press the button labeled "Restore" to have it completely calculate parity based on the drives remaining in the array.  Restore does not restore data, but an initial config prior to parity calcs based on the existing working assigned disks.

 

You will be without parity protection while this full parity calculation occurs, so before you go through this procedure, it is suggested you do a preliminary full parity check to uncover any existing issues that will prevent the parity calc from completing properly.  (Press the parity check button, wait for it to finish, check the syslog for any errors. If no errors, then stop the array, un-assign the drive, and press Restore to calc parity without it.  The cache drive is outside of the protected array, so to remove it from being a data drive, all parity must be recalculated without it)

 

Once parity is re-calculated, you can then stop the array once more and assign the old drive to its new role as the cache drive.

 

If you do not delete the files before you unassign a data drive, you can always use uniix utilities to delete the existing partition and let unRAID rebuild it.  Or, you can use the preclear_disk.sh script to clear and partition the disk for you.

 

(I'd suggest the preclear script, as it is designed to prevent you from shooting yourself in the foot and accidentally clearing a drive assigned in your array.)

 

Joe L.

Thanks Joe.  As usual, a thorough and clear reply.  Much appreciated.

To make it easier on you, you should probably delete any files from the data drive before you un-assign the data drive, otherwise they will be there when you assign it as a cache drive and subsequently moved to the data drives when the cache-mover script first runs.

 

This got me thinking, what if I had a data drive populated with data that I wanted to convert to a cache drive, but I didn't want to move all the data off manually....  If I trust the drive to not fail during the parity rebuild, I could simply stop the array, reassign it as a cache drive, then hit 'restore' to calculate new parity info with the remaining data discs, then (after parity is recalculated) hit 'move now' and send the now unprotected data from the cache drive back into the protected array?  The advantage I see is saving some time in letting the mover script move all the data back into its correct user share, instead of doing it all manually.  Of course there is the risk of the newly appointed cache drive failing during the parity rebuild, but that risk is inherent anytime we rebuild parity info, right?

To make it easier on you, you should probably delete any files from the data drive before you un-assign the data drive, otherwise they will be there when you assign it as a cache drive and subsequently moved to the data drives when the cache-mover script first runs.

 

This got me thinking, what if I had a data drive populated with data that I wanted to convert to a cache drive, but I didn't want to move all the data off manually....  If I trust the drive to not fail during the parity rebuild, I could simply stop the array, reassign it as a cache drive, then hit 'restore' to calculate new parity info with the remaining data discs, then (after parity is recalculated) hit 'move now' and send the now unprotected data from the cache drive back into the protected array?  The advantage I see is saving some time in letting the mover script move all the data back into its correct user share, instead of doing it all manually.  Of course there is the risk of the newly appointed cache drive failing during the parity rebuild, but that risk is inherent anytime we rebuild parity info, right?

Yes, it sounds like it would work.  With the risk that the data on the array is unprotected while parity is being calculated, and the data on the disk being re-allocated as cache is not protected until moved off the disk once it is re-assigned as the cache drive.

Ok, another twist.  I decided that the drive I wanted to use for cache is too small for my purposes.  Some of the files I'd like to transfer are larger than the drive's capacity.  So, I pulled a spare sata 500gb from my spares (these are WD drives, so it pays to have spares).  My setup is pretty old and I'm using the original MB.  Also, all the existing drives are IDE.  I've taken a screen shot of the current drive assignments and I'm on 4.4.2.  I'd like to replace the small IDE drive (no files on it) with the new 500gb sata drive, and make that drive a cache drive.  I assume the correct procedure is:

 

+ Unassign the small IDE drive.

+ Hit Restore

+ Physically remove the too small sata drive (can probably be done before I hit Restore)

+ Add the new sata drive

+ Hope it doesn't screw up the other drive assignments (and fix it if they show up in the wrong order)

+ Assign the new drive as a cache drive (not sure where this selection is made...also, I probably need to format the new sata drive somewhere along the way).

 

Make sense?

 

 

Stop the array (Press "Stop" on the main unRAID management page)

+ Unassign the small IDE drive.  (on the devices page)

+ Hit Restore  And then press "Start" to re-start the array. (this will recompute parity without the small IDE drive, forgetting it ever existed in the array) You will need to check the checkboxes under each button to enable them.

After parity is re-calculated, Stop the array once more and then Power Down before physically removing or installing ANY drive  (SATA may allow hot-plugs... unRAID DOES NOT have hot-plug capability)

+ Physically remove the too small sata drive (can probably be done before I hit Restore) I do not recommend its removal with the power on.

+ Add the new sata driveDo this while powered down.

Power up and start the array. 

+ Hope it doesn't screw up the other drive assignments (and fix it if they show up in the wrong order)

+ Assign the new drive as a cache drive (not sure where this selection is made...also, I probably need to format the new sata drive somewhere along the way).

  No need to format the cache drive.  unRAID will do this after you assign the disk as the cache drive, and then create a file-system on it.

Make sense?

With the changes, yes.