RAID migration, expansion and future storage manamgement in ZimaOS

Operating System ZimaOS
1

Hello IceWhale team,

I am currently using ZimaOS with the intention of a future expansion, and would appreciate clarification about its RAID migration and expansion capabilities for ZimaOS that are key to my plan.

My concern is whether users can change their storage configuration as their needs evolve, without having to back up all their data, recreate the storage arrangement, and restore everything.

I have two specific scenarios:

1. Converting two independent disks into RAID 1

Suppose a user initially has two independent disks:

  • Disk 1 contains existing data and is being used as standalone storage.

  • Disk 2 is also configured as independent storage, but could be empty.

At a later time, the user wants to convert these two disks into a RAID 1 mirror: Does ZimaOS support this conversion while preserving the existing data on Disk 1? If not, is there a technical limitation in the current storage architecture, or is this functionality simply not implemented in the user interface?

2. Adding a third disk and changing an existing RAID configuration

Suppose a user initially creates a RAID 1 array using two disks. Later, a third disk is installed, and the user wants to convert the existing RAID 1 array into RAID 5 to increase usable capacity while retaining redundancy: Does ZimaOS support this operation without destroying the existing array or requiring the user to back up and restore all the data?

More generally, which RAID-level migrations are currently supported? For example:

  • RAID 1 ā†’ RAID 5

  • RAID 5 ā†’ RAID 6

  • Adding a disk to an existing RAID 1 array, either to increase redundancy or change the RAID configuration.

If either of the two scenarios described above is not currently supported:

  1. Is this functionality being considered for future ZimaOS releases?

  2. Is there a roadmap for implementing these migration capabilities with a timeframe?

  3. Are there technical reasons why these operations cannot be supported with the current Btrfs/RAID implementation?

These are not unusual requirements in NAS storage management, and other systems (Synology DSM, TrueNAS, Unraid) have implemented these or variations to solve these scenarios.

I believe these are important capabilities for a NAS platform. Users should be able to start with a small storage configuration and expand or change their redundancy strategy as their storage requirements grow, without being forced to migrate all their data to temporary storage every time.

Thank you.