It is worth noting that there is a method whereby you zero the disk via the command line in a console/telnet session, and then having done that do a new Config; add the drives omitting the one to be removed; and use the Trust parity option to start up the array with parity still valid.

 

Pros: 

- Parity remains valid throughout the process.

 

Cons:

  - you are not protected against a mistake in the command line causing you to write to the wrong disk and therefore lose data. 

- It can take a long time to zero the disk to be removed if it is a large one.

 

Maybe integrating this into the Web GUI or a plugin might be a possibility.

It is worth noting that there is a method whereby you zero the disk via the command line in a console/telnet session, and then having done that do a new Config; add the drives omitting the one to be removed; and use the Trust parity option to start up the array with parity still valid.

 

Pros: 

- Parity remains valid throughout the process.

 

Cons:

  - you are not protected against a mistake in the command line causing you to write to the wrong disk and therefore lose data. 

- It can take a long time to zero the disk to be removed if it is a large one.

 

Maybe integrating this into the Web GUI or a plugin might be a possibility.

And while this would be possible with a failed/emulated disk, same obvious risks of running without parity protection as already noted.

Plus, the whole zeroing would take longer than just invalidating the array and rebuilding parity without the drive. There are no pro's to zero'ing a failed and emulated drive before removing it.

Plus, the whole zeroing would take longer than just invalidating the array and rebuilding parity without the drive. There are no pro's to zero'ing a failed and emulated drive before removing it.

Yes there are.  With that process you always have valid parity.

Plus, the whole zeroing would take longer than just invalidating the array and rebuilding parity without the drive. There are no pro's to zero'ing a failed and emulated drive before removing it.

Yes there are.  With that process you always have valid parity.

 

There is no point in having a prolonged period of "valid" parity while a disk is failed. It serves absolutely no useful purpose.

 

Now, keeping parity by using the process on a healthy array does make sense.

 

It is worth noting that there is a method whereby you zero the disk via the command line in a console/telnet session, and then having done that do a new Config; add the drives omitting the one to be removed; and use the Trust parity option to start up the array with parity still valid.

 

Pros: 

- Parity remains valid throughout the process.

 

Cons:

  - you are not protected against a mistake in the command line causing you to write to the wrong disk and therefore lose data. 

- It can take a long time to zero the disk to be removed if it is a large one.

 

Maybe integrating this into the Web GUI or a plugin might be a possibility.

 

This is an interesting option. I don't understand how this would work, ultimately, though, because the parity on the parity disk is block level (or device level) XOR data. So, if I understand XOR correctly, when the parity is used to rebuild the missing disk it will rebuild it block-for-block, back to 2TB. If this is so, wouldn't it just give me an error while rebuilding on to a 1.5TB disk?

 

Since it's always possible that I misunderstood you, if the purpose of this process is not to rebuild from parity, then I'm inclined to agree with lionelhutz. Why bother trying to maintain valid parity throughout the procedure?

I think itimpi was just mentioning a way to remove a drive without invalidating parity. I don't think it really applies to the scenario of rebuilding onto a smaller drive, and it probably doesn't make sense to use that method with a failed/emulated disk.

 

One thing that does make sense when running with a failed/emulated drive. Stop writing to the array, and copy any critical files you don't have backed up from the emulated drive to another system.

 

Of course, you really should have critical files backed up elsewhere so this shouldn't be necessary.

... wouldn't it just give me an error while rebuilding on to a 1.5TB disk?

 

Just to be clear, you can NOT rebuild to a 1.5TB disk => as we've said several times, that is NOT supported by UnRAID.  If you have a failed 2TB drive, you can only rebuild onto another 2TB disk (or larger - up to the size of your parity drive).

 

What we've outlined are ways you could in fact REPLACE the failed disk with a smaller disk -- but you'll lose ALL of the data on the 2TB disk in the process ... so before you do that you'd need to copy any of the data you need from that disk to another location.

 

The "zero in place" process is really useless in this scenario.  While it does indeed, in a good array, allow maintaining parity while removing a disk, that's not really the case here.    With a failed disk, you're already "running at risk".  You do indeed have good parity -- but the ONLY disk it's protecting is the one that's failed.    It IS possible to zero the emulated disk, and then remove the failed disk using New Config with "Trust Parity" to get back to a protected array ... but the time to do this will be LONGER than simply doing a New Config without the disk and a new parity sync.

 

... and note that, as I've also emphasized earlier, as soon as you make ANY change to the configuration you will lose the ability to access the emulated disk => so be certain you have backups of the data on it before doing anything else.

 

One More Time:  By FAR the best approach is to use a replacement drive that's at least as large as the failed drive and simply let UnRAID work as designed by rebuilding the failed drive.

 

...

This is an interesting option. I don't understand how this would work, ultimately, though, because the parity on the parity disk is block level (or device level) XOR data. So, if I understand XOR correctly, when the parity is used to rebuild the missing disk it will rebuild it block-for-block, back to 2TB. If this is so, wouldn't it just give me an error while rebuilding on to a 1.5TB disk?

...

And to make this even clearer since it hasn't perhaps been stated in this way, unRAID will not even let you attempt this. If you replace a disk with one smaller than the original it will not proceed with the rebuild.

To make things clear, unRAID operates on the partition, not the device. The disk will appear unformatted if you could cause unRAID to do an operation where it only rebuilds the disk using the parity data. A rebuild requires first creating the partition and then rebuilding the data onto the partition. So, in theory if you could rebuild onto a smaller disk if you could first shrink the partition down the size of the smaller disk.

 

To make things clear, unRAID operates on the partition, not the device. The disk will appear unformatted if you could cause unRAID to do an operation where it only rebuilds the disk using the parity data. A rebuild requires first creating the partition and then rebuilding the data onto the partition. So, in theory you could rebuild onto a smaller disk if you could first shrink the partition down the size of the smaller disk.

 

Everything I have seen says that unRAID is device level, but this makes a lot of sense... at least theoretically. I don't think there would be any way to shrink a partition that hadn't been created yet. From a user standpoint, at least as unRAID sits presently, this is probably strictly theoretical. LT would have to add support to the software to make this usable. I agree that it could be done, but I don't know if they would bother for the reasons stated earlier in the thread.

Candidly, there's simply no reason to ever do what you've suggested.    If you have a failed disk, and truly can't afford to buy a replacement AND don't have any backups, you can simply copy the data from the emulated disk to either another disk on the array (if there's space) or to a smaller drive that has the space you need, which you can attach to another system, or that you mount "outside" the array on the UnRAID server.

 

But at the cost of disks these days (practically free compared to what some of us have paid in the past) it's hard to believe that if you can afford to build a fault-tolerant server to hold TB's of data, and to collect the data for that server, that you can't afford a spare disk 

I don't think there would be any way to shrink a partition that hadn't been created yet.

 

Now you've got the crux of the issue. Shrinking a partition on a drive that doesn't physically exist.

Candidly, there's simply no reason to ever do what you've suggested.    If you have a failed disk, and truly can't afford to buy a replacement AND don't have any backups, you can simply copy the data from the emulated disk to either another disk on the array (if there's space) or to a smaller drive that has the space you need, which you can attach to another system, or that you mount "outside" the array on the UnRAID server.

 

But at the cost of disks these days (practically free compared to what some of us have paid in the past) it's hard to believe that if you can afford to build a fault-tolerant server to hold TB's of data, and to collect the data for that server, that you can't afford a spare disk 

 

Right. It just makes me feel better. When I purge data, if I have tons of free space sitting on my server I like to pull disks. I don't like waste, that's really what it comes down to. There are a few situations where this feature would be helpful, but only one of them is a necessity: when you want to take an array of n disks down to n-1 because you don't have one / don't want one / don't need to replace that disk. If there is currently no good way to do this, then this thread is resolved.

 

I do still think that this feature should be present in the next version of the software, especially now that btrfs is supported on data and cache drives.

... It just makes me feel better. When I purge data, if I have tons of free space sitting on my server I like to pull disks. I don't like waste, that's really what it comes down to. There are a few situations where this feature would be helpful, but only one of them is a necessity: when you want to take an array of n disks down to n-1 because you don't have one / don't want one / don't need to replace that disk. If there is currently no good way to do this, then this thread is resolved.

 

I do still think that this feature should be present in the next version of the software, especially now that btrfs is supported on data and cache drives.

9 Page thread about removing a disk while maintaining parity.

Thanks for posting that. I just rummaged through that thread and have a good idea of how to drop a drive from the array while keeping valid parity. My only clarification is about the "move all your data from the drive you want to remove" step. Do you do this with the unbalance plugin, or some other way?

 

If I zero a drive full of data, I just lose all of my data...