ZFS is a file system that can work with most operating systems. Soon there will be a fully functional version even under MS Windows.
Other directions are more convenient for private end-users. When using ZFS at home, there is a problem that the volume grows either by installing a new Vdev or by replacing all the disks in the Vdev with larger ones (ZFS sees that the disks have grown and can use the extra space). Having assembled one RAIDZ, we cannot add another disk to it on the go, already in the alpha patch that allows you to do this.
Another interesting development being prepared for release is a new type of Vdev – dRAID. In large installations, where disks are measured in hundreds and space is in petabytes, it is difficult to restore data redundancy if one disk fails quickly.
The problem is that hard drives growing to 20TB or more don’t add much performance in terms of throughput. Any disk has several errors per terabyte read, officially declared by the manufacturer ( URE – unrecoverable read error rate ). And any RAID 5 or more with disks larger than 3 TB is almost guaranteed to fall apart during reassembly when one disk has crashed, and we are reading from the rest. The risk of a read error of at least one wrong byte from this 3 TB of each disk is simply huge (for “consumer” HDDs, the standard is one read error for every 10^14 bits, i.e., for every ~11TiB). When we rebuild RAIDZ, which is the same RAID 5, 6, and so on, there is the same problem.
Of course, we can increase the number of disks that we can lose: install RAIDZ 2, RAIDZ 3 – how many copies will be stored, but we do not solve the issue of recovery performance. The new disc we are replacing is still a bottleneck. This 15 – 20 TB will be restored at best at a speed of 200 MB / s (and in a realistic – about 100 MB / s, or even less). Several days to restore one disk is a very long time.
dRAID solves the problem of simultaneously recovering data on many drives. Instead of working within the framework of “one disk – one unit”, we cut each disk into small entities according to the number of disks. So, if there are 50 disks in dRAID, they will be divided into ~50 areas. Some of these areas will be reserved as free (spare) areas to which you can recover.
It’s RAID 5 or RAIDZ rotated 90 degrees. We have virtual entities within physical disks. If one drive crashes, then free space is reserved for the others; you can restore the crashed drive at a speed that depends on the number of elements in the array. We can recover ten disks at once when we have ten data blocks. This approach increases the speed of recovery.
For example, we have assembled dRAID, similar to RAIDZ2, with one spare disk, allowing two disks to fail, and one failed, nine remained. Before we insert a new disk, we spread the data on the empty reserved space of other disks in the group. And so we restore the situation: there are still nine disks, but two can fly out, and not one because the blocks from the flying disk have already dispersed to the remaining surviving ones. Thus, the problem of a bottleneck in the form of the performance of a spare disk is removed; technically, it is now spread over other disks in the array.
For the same reason, now you can use a spare disk; in RAIDZ, it would be idle, and in dRAID, it is an active participant. Spread across all disks.
Also Read: Everything You Need To Know About Extortion Viruses
