ZFS Array system

[DanielFerr97]

I would like to share an idea and also ask for feedback from the OpenZFS community about a feature that I believe could be very useful for many people working with large long-term storage environments.

I am not a filesystem developer or kernel programmer. I am an electromechanical engineer and I use TrueNAS and OpenZFS mainly for industrial and professional storage environments with a very large amount of files such as CAD projects, technical documentation, industrial archives, old machine data, scanned documents, and historical project backups.

In many companies, especially in engineering, media production, medical imaging, legal archives, and industrial environments, we accumulate thousands or even millions of old files that almost never get accessed again. However, these files cannot simply be deleted because of compliance requirements, project history, traceability, customer support, or internal policies.

The problem is that these files still need to stay inside the same logical folder structure and network path. For example:

/company/projects/project_1/
/company/projects/project_2/
/company/projects/project_3/
etc.

Many applications, databases, scripts, and production workflows depend on absolute paths (SolidWorks). So moving old files to a completely separate archive pool or external cold storage system is often not practical because it breaks links and workflows.

At the same time, traditional RAIDZ vdevs in OpenZFS are optimized mainly for performance, redundancy, and balanced striping across all disks. This is excellent for active production workloads, but for cold archival data it creates an energy and hardware efficiency problem.

If I need to open a single old file from 10 years ago, all disks in the RAIDZ vdev may need to spin up because the blocks are distributed across every drive. In large storage systems this means:

unnecessary power consumption,
additional heat generation,
mechanical wear,
noise,
and reduced HDD lifespan.

This is why many home users and even some professional environments are attracted to systems like Unraid or MergerFS + SnapRAID.

What people like about these systems is not necessarily the performance, but the operational behavior:

independent disks,
mixed drive sizes,
only the required disk spins up,
partial failure isolation,
and simpler archival-oriented storage.

However, these solutions also have important limitations compared to OpenZFS:

weaker or missing end-to-end data integrity,
no native checksumming against bit rot,
weaker snapshot systems,
weaker self-healing,
no integrated OpenZFS ecosystem,
or parity systems that are not fully real-time.

So I started wondering if OpenZFS could eventually support some kind of new archival-oriented vdev type or storage class designed specifically for cold data.

The idea would not be to replace RAIDZ or mirrors, because those are still perfect for production and active workloads.

Instead, this would be something more similar to an "asymmetric archival vdev", where:

files are mostly kept together on individual disks instead of striped across all disks,
disks could have mixed sizes,
only the required archive disk would spin up during reads,
and parity protection would still exist inside the OpenZFS ecosystem.

The dream scenario would be something like:

fast SSD/NVMe mirrors for active projects,
traditional RAIDZ for production workloads,
and a new cold archival storage tier for old inactive data.

For example, after a file has not been modified for 1 or 2 years, OpenZFS could automatically migrate it to this archival tier while keeping the exact same visible path to the user.

Something conceptually similar to:

/company/projects/active/
/company/projects/archive/

but completely transparent internally.

I know this is probably extremely difficult from an architectural perspective and maybe even impossible within some parts of the current OpenZFS design.

I also understand that OpenZFS is block-based and not file-based, so I may be thinking about this from the wrong angle technically.

Still, I wanted to ask the community and developers if some kind of feature like this has ever been discussed before, or if there are architectural reasons why it could never work.

From a practical user perspective, I think there is a very large gap today between:

high-performance enterprise storage,
and long-term energy-efficient archival storage.

And I feel OpenZFS could potentially become amazing at both.

I would really love to hear thoughts from people who understand the internals of OpenZFS much better than I do.

[NicholasRush]

Hello @DanielFerr97 ,

My idea might potentially offer a solution. I have described it here: #14741 (comment)
It aims to introduce an additional abstraction layer within OpenZFS designed to decouple all RAID handling and physical block placement from the virtual ZFS block. This would offer the following advantages: improved storage utilization through sub-block compaction, inline and background deduplication, compression, and encryption, as well as the capability for temperature-dependent data compression.

I am not a file system developer. However—much like you—I have been thinking about how OpenZFS could be improved.

[gmelikov]

Many applications, databases, scripts, and production workflows depend on absolute paths (SolidWorks). So moving old files to a completely separate archive pool or external cold storage system is often not practical because it breaks links and workflows.

FWIW, you may easily change mount point, dataset name != mount name (see zfs get mountpoint) and don't enable automount. And, you may easily make a bind mount to have different mount point of already mounted FS.