NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
X-RAID 2 Operation and Downsizing
I've tested answers in other posts on my NAS and found some of them to be incorrect, so please cite when you can to support your response. Questions: (1) If I lose a disk in a RAID-5 and don't h...
Learning2NAS wrote:
Hey Stephen,
Thanks for answering my questions. You addressed everything in my original post, but I have a clarification to your response to #2 (quoted below). Using your hypo, if I have a base layer of 1TB that is always there and my current array is 1x1TB (original disk that hasn't died yet) and 2x3TB, can I replace the 1x1TB with another 1TB? Additionally, can I replace the 3TB with a 1TB if it fails? It sounds like the answer to that second question is no, because there might be data stored somewhere in the 2TB layer, but I just want to verify this.You can replace the 1 TB drive with another 1 TB drive. But you can't replace the 3 TB drive with a 1 TB drive.
Learning2NAS wrote:
If that's true, that brings me full circle back to what I'm having such a hard time understanding: when you have a failure in RAID 5 there is enough redundancy to rebuild an effected file from the remaining drives (that's the point, right?). With this being so, I don't understand why the RAID can't rebuild the missing files on any size drive I stick in, so long as it is at least large enough to support the amount of data that needs to be striped to the new drive.
The RAID software sits between the physical disks and the file system - and has no idea about how the file system is organized (e.g., where files are stored, and where there is free space; or even what the file system is). When you replace a drive, the RAID software reconstructs all the disk blocks on the drive from the blocks on the other drives (whether there is data in them or not). Likewise, a resync always takes the same amount of time, no matter if the file system is full or empty. So RAID treats all data blocks on the drives identically (used or not).
There potentially are some advantages to fully integrating RAID-like redundancy into the file system itself - then features like the ones you are envisioning would be easier to do. The BTRFS team is working on a design like that, but it is still experimental - so Netgear (wisely) isn't using it. If they were to switch to it, it would likely require a factory reset.
Hey Stephen,
Thanks for answering my questions. You addressed everything in my original post, but I have a clarification to your response to #2 (quoted below). Using your hypo, if I have a base layer of 1TB that is always there and my current array is 1x1TB (original disk that hasn't died yet) and 2x3TB, can I replace the 1x1TB with another 1TB? Additionally, can I replace the 3TB with a 1TB if it fails? It sounds like the answer to that second question is no, because there might be data stored somewhere in the 2TB layer, but I just want to verify this.
If that's true, that brings me full circle back to what I'm having such a hard time understanding: when you have a failure in RAID 5 there is enough redundancy to rebuild an effected file from the remaining drives (that's the point, right?). With this being so, I don't understand why the RAID can't rebuild the missing files on any size drive I stick in, so long as it is at least large enough to support the amount of data that needs to be striped to the new drive. Ex: Assume the array above only has 200gb of data on it, for whatever reason. Sticking in a 1TB replacement for a 3TB drive shouldn't cause a problem, as no data in the "new" 2TB layer is missing (yet) because it can be rebuilt from the other drives, and whatever the rebuilt stripes look like will easily fit on a 1TB replacement disk. So why wouldn't this be possible? A rebuild is a rebuild, right?
StephenB wrote:
(2) Since X-RAID 2 works by creating layers, does the answer to (1) change if my array was originally created on smaller disks, and my temporary disk is the size of the original disks that my volume used to be made of? Or do those layers disappear each time the volume expands?
The layers never disappear. So if you start with 3x1TB, the array will always have a 1 TB base layer. If you then expand to 1x1TB+2x3TB, the array will aways have a second 2 TB layer. It doesn't change the answer to (1).
Learning2NAS wrote:
Hey Stephen,
Thanks for answering my questions. You addressed everything in my original post, but I have a clarification to your response to #2 (quoted below). Using your hypo, if I have a base layer of 1TB that is always there and my current array is 1x1TB (original disk that hasn't died yet) and 2x3TB, can I replace the 1x1TB with another 1TB? Additionally, can I replace the 3TB with a 1TB if it fails? It sounds like the answer to that second question is no, because there might be data stored somewhere in the 2TB layer, but I just want to verify this.
You can replace the 1 TB drive with another 1 TB drive. But you can't replace the 3 TB drive with a 1 TB drive.
Learning2NAS wrote:
If that's true, that brings me full circle back to what I'm having such a hard time understanding: when you have a failure in RAID 5 there is enough redundancy to rebuild an effected file from the remaining drives (that's the point, right?). With this being so, I don't understand why the RAID can't rebuild the missing files on any size drive I stick in, so long as it is at least large enough to support the amount of data that needs to be striped to the new drive.
The RAID software sits between the physical disks and the file system - and has no idea about how the file system is organized (e.g., where files are stored, and where there is free space; or even what the file system is). When you replace a drive, the RAID software reconstructs all the disk blocks on the drive from the blocks on the other drives (whether there is data in them or not). Likewise, a resync always takes the same amount of time, no matter if the file system is full or empty. So RAID treats all data blocks on the drives identically (used or not).
There potentially are some advantages to fully integrating RAID-like redundancy into the file system itself - then features like the ones you are envisioning would be easier to do. The BTRFS team is working on a design like that, but it is still experimental - so Netgear (wisely) isn't using it. If they were to switch to it, it would likely require a factory reset.
I'm following you now. It seems like when XRAID 2 initializes a disk for the first time it creates the RAID "container" (I don't know the technical term for this proprietary RAID, but I'm thinking LVM like functionality in BTFRS) so that it fills the disk. Since RAID operates at the block level, the next disk must be able to hold at least the current container. The RAID controller isn't able to shrink the container to fit the new drive because the controller doesn't know where the data is inside the container, it just copies/rebuilds block by block. So install too small of a drive and system will probably just ignore it.
That's pretty cool, and very helpful to understand.
I did some searching before writing this reply and I found several products that are playing with file system RAID. As far as Netgear is concerned, only some of their enterprise products advertise block-level replication (Netgear ReadyDATA in particular). How do you know that "prosumer" products running OS6 are using block level RAID, rather than a software based file system RAID?
I think you're right, I just like to have test results or a source to cite. I intend to test this sometime soon. I will post results in the next few days for all who are/may be curious in the future.I will mark your answer as the solution once I confirm its accuracy. Thanks for your time =)
Learning2NAS wrote:
How do you know that "prosumer" products running OS6 are using block level RAID, rather than a software based file system RAID?
Software raid on linux is block-level. ZFS and BTRFS are the only file systems I know of that have attempted to integrate raid features into the file system itself (there could be others, but I don't know of them).
BTRFS's RAID integration isn't mature/stable. ReadyNAS definitely runs mdadm (https://en.wikipedia.org/wiki/Mdadm). You can see the layering partitions in the downloaded logs.
Test results are in. I found a useful blog post about shrinking linux software RAID sizes here (http://www.starcoder.com/wordpress/2011/08/shrinking-a-linux-software-raid-volume/). Those instructions allow you to easily shrink a partition, to remove a disk from the array, or both. However, that process only works smoothly with a manually configured RAID array. Since Netgear devices default to XRAID2 and create multiple layers on each drive, it is more complicated than those instructions. It is still theoretically possible to reduce the size of an XRAID2 and you would do it by repeating the steps in that blog post, however it is a time intensive process and there is no guarantee that it will work (in my case, I had a small stripe that was created by XRAID2 that was 100% full, and spread across several drives, so I could not resize that small stripe whatsoever. This proved fatal to my shrink operation, and made it fail.).
In the end, I was not able to resize my XRAID2 array without destroying the volume and having the device rebuild it. If this function is important to users, they should be mindful to build a Flex-RAID array when commissioning their devices (however, this is more complicated and should be reserved for somewhat experienced users).
I also tested the automatic functions of XRAID to confirm that it was unable to shrink a drive on its own. When you insert a drive smaller than the one that was there previously, the system just throws and error and continues to operate in degraded mode. It will not shrink a volume, automatically or otherwise.
I appreciate your time, Stephen. Hopefully this is helpful to someone in the future.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
