On 9/8/2026 at 3:50 AM, tjb_altf4 said:

With Unraid 8 in development, will we still see multi array in 7 series, or will it be pushed back again?

https://forums.unraid.net/topic/200239-unraid-8-explained-fedora-docker-compose-faster-security-updates/#findComment-1633920

Multiple arrays: a working proof of concept

Multiple arrays turned out to be within easy reach, so I built a proof of concept to show how little is actually needed. It is meant as a demonstration for Limetech and anyone curious, not as something to run on your server.

Please don't install this on a production server. It loads its own copies of the parity driver and has only been tested in a VM. Use a test box or a VM with disks you don't care about. The goal is to show that proper built-in support is close, not to replace it.

Why it's simpler than it sounds

Each array is already a self-contained unit, so a second array just needs a second copy of the same stack:

- Parity driver: one more copy of Unraid's own md driver per extra array, under its own name (a ~200-line rename patch).

- Array management, user shares, mover: unchanged. Each extra array runs Unraid's own components with its own config, state and /mnt.

- Main tab: Main2, Main3 … are generated from the stock Main page of the running Unraid version, so they look and work the same (Start/Stop, Check, Spin up/down, live stats).

- Disks: Settings › Multi Arrays has a pinning grid, same idea as CPU Pinning: each disk belongs to one array, and an array only sees its own disks. Hot-plugged disks show up on their own.

No Unraid file is modified and the whole thing is under 800 lines. The arrays never need to talk to each other; moving data between them is just a copy from one mount to another.

To make the GUI side even easier to adopt, I've opened a pull request on the webGUI that lets the stock Main page sections take an array number instead of assuming a single array (no change for existing setups): https://github.com/unraid/webgui/pull/2813

What was tested (Unraid 7.3.4 in a VM, three arrays running at once): parallel parity syncs and checks (0 errors), a pulled disk with emulated reads and a rebuild, start/stop of the main array taking the others along, and install/upgrade/removal.

What a proof of concept leaves out: share export (SMB/NFS) and scheduled jobs for the extra arrays, per-disk pages and parity history on the extra tabs, and a driver build for every kernel. All of that is ordinary work once it lives inside Unraid itself.

Why now, and not wait for Unraid 8

@tjb_altf4 asked whether multiple arrays will still come in the 7 series or move to Unraid 8.

Unraid 8 was announced in August without a release date, and moving to a new base OS is a big job of its own, so my estimate is that it is well over a year away. And a release date is not the date people can use it: nobody moves a multi-TB production server to a new base OS on day one. Most will wait for it to settle, and for the whole ecosystem built up over the 6 and 7 series, every plugin and every App (container template), to be ported and field-tested on the new base. That adds many months more. Plenty of servers are still on 6 today, simply because their owners have had no real reason to change, and a new base OS alone won't give them one. Multiple arrays were promised for the 7 series, and this shows they fit there: nothing in this approach depends on the base OS, so the same design carries straight over to Unraid 8 afterwards.

Carrying the arrays themselves from 7 to 8 is just as simple. Unraid 8 will read the same on-disk format and use the same methods as 7, because otherwise nobody could upgrade: nobody is going to be asked to convert multi-TB arrays. An extra array is exactly that format (the same parity layout and the same disk filesystems), with its own config folder on the flash. So Unraid 8 will support it natively from day one. And even if Unraid 8 shipped with no multi-array support at all, upgrading a multi-array server would still just work: the main array is untouched by all this and starts as usual, and the extra arrays simply sit idle as unassigned disks with their data and parity intact, waiting for the logic to arrive. That is how native this is: nothing about the main array or the disk format changes. (The one rule while they wait: don't assign or format those disks elsewhere.) The only thing that decides whether multiple arrays are there is whether the logic is included in Limetech's code, and that logic can go into the 7 series today.

For everyone who has asked for this over the years: @Lolight @my.name.jeff @Raki72 @hawihoney @marcelunraid @niteman1969 @Gabcraftia @jcm808 @I Enjoy Creating Videos @PeterDB@Jerky_san @swamiforlife @Rudder2 @jortan @XDUDE3D @Maximus01701 @aglyons @StancuFlorin @PiMan314159265

Disclaimer: Multi Arrays is an independent project, not made or supported by Lime Technology. Neither its author nor Lime Technology takes any responsibility for any results caused by this plugin or its implementation. It is a proof of concept, meant only to show how simple support for multiple arrays could be. If that doesn't sit well with you, wait for the official support for multiple arrays in Unraid.

Edited 5 hours ago5 hr by Samsonight
formating

On 11/2/2026 at 4:26 PM, Samsonight said:

What a proof of concept leaves out: share export (SMB/NFS) and scheduled jobs for the extra arrays, per-disk pages and parity history on the extra tabs, and a driver build for every kernel. All of that is ordinary work once it lives inside Unraid itself.

Import of an exisiting array might be an additional task. I'm using VMs for additional arrays and would like to consolidate them to the host once multiple arrays are available.

4 hours ago, hawihoney said:

Import of an exisiting array might be an additional task. I'm using VMs for additional arrays and would like to consolidate them to the host once multiple arrays are available.

How are yours set up? In detail, where possible.

Good point. Bringing arrays from several Unraid servers together on one server is exactly what multiple arrays should make easy, so I'm planning an export/import for the plugin:

- Export on each old server: a file with each slot's disk (serial, size, parity or data, slot number) and the array's own settings. No passwords or keys.

- Import on the new server: the file becomes the main array or an extra one. Unraid recognises array disks by serial number and size, so the import matches each slot the same way, shows you the full plan before anything is written, and stops if a slot doesn't match exactly one free disk. Slot order is kept as it was, which matters with two parity disks, and nothing is formatted.

Then the disks start in their old slots with parity still valid, with no guessing which disk was parity.

For arrays in VMs it depends on how the disks reach the VM. If each VM gets its controller passed through, the VM sees the real disks with their real serial numbers, and the import is the same pure mapping: no copying and no new parity sync. With virtual disks or disk images it would mean copying the data and building parity again, which an import can't avoid.

Disclaimer: Multi Arrays is an independent project, not made or supported by Lime Technology. Neither its author nor Lime Technology takes any responsibility for any results caused by this plugin or its implementation. It is a proof of concept, meant only to show how simple support for multiple arrays could be. If that doesn't sit well with you, wait for the official support for multiple arrays in Unraid.

Edited 5 hours ago5 hr by Samsonight
disclaimer