Unraid

Unraid (https://unraid.net/) is a NAS OS that does not use RAID but spreads the files across individual volumes instead. Each volume has its own filesystem.

The array layout

The layout in Unraid is different from the typical RAID layout. The typical RAID has one filesystem per RAID and spreads all blocks, both metadata and file data, across all member disks. Unraid has one filesystem per disk, and each file is placed onto one of the filesystems. If we have two disks and three files (A, B, and C) with one metadata block and two data blocks per file, the simplified layouts look like this:

Traditional RAID5 layout (left) vs. Unraid data layout (right)

For parity, Unraid uses one dedicated disk, a la RAID4. For two parities, equivalent to a RAID6, Unraid uses a second dedicated disk. Unraid provides a choice between XFS (default), BTRFS, or ReiserFS for the filesystem. You can mix different filesystems in one array.

Because Unraid never splits files, there is an issue of balancing files across multiple disks, but I don't think it is significant in real-life use.

Another notable difference is that you don't get a speed boost associated with regular RAID because Unraid stores each file on one disk. Unraid can't split the read (or write) operations across multiple disks.

Another similar storage system, StableBit DrivePool, uses a similar scheme but under Windows.

The failure modes

Because of the difference in layout, Unraid failure modes differ from conventional NAS/RAID systems.

In a conventional RAID system, there is only one set of RAID metadata and one set of filesystem metadata. So, if one or the other is damaged, all the files become unavailable. Because a conventional RAID spreads all data across all disks, the recovery involves the entire disk set.

In Unraid, if top-level metadata is damaged, the files are still available by merging all the directories from the individual filesystems. The predominant failure mode will be one of the filesystems crashing and taking its part of files with it. However, the files on the undamaged disks (and their corresponding individual filesystems) will remain unaffected.

Recovery strategies

Recovery strategies also have to adapt according to the failure modes.

On the bright side, you need significantly less disk space to recover from a single failed filesystem in Unraid than you need to recover from a traditional RAID failure. The traditional RAID requires enough free space to accommodate the entire content of the array, after which you have to rebuild the entire array in one go. The Unraid requires space to accommodate just the content of the failed disk, after which you can reintegrate the data into the Unraid without touching the good disks. If something crashes in Unraid that the entire system goes down, it can be rebuilt and fed the data disk-by-disk, requiring two blank disks (one for data and one for parity in a system being rebuilt).

Bonus: Unraid VMWare VM setup

The Unraid installation in VMWare is about as easy as can be expected.

1. Download the Unraid USB creation tool.
2. Create a bootable USB (leave "Enable UEFI boot" checked).
3. Create a blank VMWare VM, Ubuntu x64 compatibility (other modes probably work too, but I did not test), then configure it for UEFI boot in "VM Settings", then "Options", then "Advanced", then switch "Firmware type" to "UEFI" with no secure boot.
4. Start up the VM and quickly hit ESC to get into the UEFI shell.
5. Attach the USB drive to the virtual machine, then configure UEFI to boot from that USB drive.

With this done, Unraid will boot in VMWare Workstation, and the only remaining thing to do is to pass disks to the VM as required.

One minor detail, the write speed on my setup was pathetic.

The test set I commonly use is 200 GB in 100,000 files and 4000 directories. It took between 18 and 24 hours to copy the test set to the array via SMB (I wasn't there when it finished). At some point, it was two to three seconds per small file (16 KB or less). I am not sure if it was some artifact of my setup, of virtualization, or if something in the write path just hates many small files. I decided not to spend any effort on figuring this out.

Filed under: NAS.

Created Wednesday, January 11, 2023