Is there a way to park drives for later?

[FlyingTexan]

I redid my media and went HEVC for it anywhere I could find it. Making that shift really freed up space. I could easily remove 4 drives and shelve them somewhere but honestly I don't want to have to shut the sever down and go through all the hassle of pulling drives.  Is there a way to take the data that's spread across a few drives, shift it to the rest of the drives, and somehow just park those drives so they can be physical spares in the future? Basically tell unraid to never spin them up or use them? 

[Frank1940]

Have you thought about 'unassigning' them and leaving them installed as 'hot spares'? 

[Kilrah]

You can move the data away then globally exclude those disks from shares, they should never be used and thus stay spun down. That assumes you're not using recostruct writes, with that they would still have to be spun up for writes as long as they're in the array.

Edited May 13, 2023 by Kilrah

[Frank1940]

59 minutes ago, Kilrah said:

they should never be used and thus stay spun down.

 

Not quite true, they will spin up for the scheduled periodical Parity Checks.  Not really a bad idea...

[JonathanM]

The only issue I see with leaving them in the array is if one of them fails, it puts your data at risk, even if they are empty. Personally I'd dev/zero them, and do a new config without them. If your server stays up for months at a time between reboots, they can stay spun down in UD, ready to be put into use at a moments notice (hot spare, sort of)

[FlyingTexan]

8 hours ago, Frank1940 said:

Have you thought about 'unassigning' them and leaving them installed as 'hot spares'? 

I haven't wanted to really do anything yet out of fear changing the array would grenade it so I wanted to hear from someone here what's safe to do before doing it lol

[FlyingTexan]

39 minutes ago, JonathanM said:

The only issue I see with leaving them in the array is if one of them fails, it puts your data at risk, even if they are empty. Personally I'd dev/zero them, and do a new config without them. If your server stays up for months at a time between reboots, they can stay spun down in UD, ready to be put into use at a moments notice (hot spare, sort of)

I liked the idea above of removing them from the array. That would essentially be doing the same thing, right? So lets say I move the data off them, spin the array down, remove two drives from the array, spin it back up.  Those two drives not in the array do they still spin up every?  I was thinking of moving the data off my two hottest drives, I can't figure out why but if the array averages 40c two of them will be around 50c during 24/7 write periods.  I'd chose those to spool down, or heck maybe leave them as an experiment, and remove the others. I'd just like to not have so many drives with only a little data on them spinning all the time.

[Frank1940]

49 minutes ago, FlyingTexan said:

I liked the idea above of removing them from the array. That would essentially be doing the same thing, right? So lets say I move the data off them, spin the array down, remove two drives from the array, spin it back up.  Those two drives not in the array do they still spin up every?  I was thinking of moving the data off my two hottest drives, I can't figure out why but if the array averages 40c two of them will be around 50c during 24/7 write periods.  I'd chose those to spool down, or heck maybe leave them as an experiment, and remove the others. I'd just like to not have so many drives with only a little data on them spinning all the time.

 

What the point is-- that leaving drives in the array (even without data stored on them) is that each drive so configured is a 'point of failure'.  The more points of failures in a array, the more likely you are to end up in a situation where you can lose data.  That is you may find that you have more drives in a failure mode than your parity configuration can handle.  Realize that a failure on an empty drive in the array can prevent the rebuilt of a failed drive that has data stored on it. 

 

Unassigning drives that are empty will require that you rebuilt parity but it also a check that all of the array drives are working at that point in time.  If you have several drives to remove, transfer the data from all of them first and unassign them all before you start the parity rebuilt.  (If you are a real belt--and-suspenders type of person, you could run a non-correcting parity check first.)

 

You can find more information about the statistics of drive failures with actual numbers here:

 

        https://forums.unraid.net/topic/50504-dual-or-single-parity-its-your-choice/

 

One more thing, a drive that has been 'emptied', still has all the ones-and-zeros that it had before the data was 'transferred'.  What Linux did was to change a few bytes in the file allocation table for each file that was moved to indicate that that disk space used for the file's data was now available to be reallocated to store a new file's data in those disk sectors as needed.  If you look at any disk that contains no files, you will find that there is still a very respectable chuck of disk space still being used.  That disk space contains those file allocation tables waiting for the next file to be transferred to that disk.  Unraid will still need to read every byte on all those 'empty' disks whenever it does any parity operation because parity operations are performed at the bit level-- not at the file level.  (That is why you can use any mixture of the four File Systems in the array!)