Veeam Repositories on Kernel 6.14+(Ubuntu 26.04): Mixing SSD and HDD with XFS rtdev

[diogomarzano]

Hello everyone!

I wanted to open this discussion to talk about a major evolution in XFS that changes the game for high-capacity Linux Hardened Repositories (LHR) in Veeam Backup & Replication: modern support for rtdev (Realtime Subvolume) with Reflink introduced in Kernel 6.14.

Until recently, using rtdev in XFS for Veeam backups was limited by historical constraints, such as the lack of reflink / Fast Clone support on the realtime volume. However, with the metadata restructuring introduced in kernels 6.14 and newer (via rtgroups and rmapbt on rtdev), it is now possible to combine HDDs (capacity) and SSDs/NVMes (performance) with surgical precision.

The Classic Problem: Fragmented I/O and Latency on HDDs
In repositories built purely on mechanical HDDs, consolidating Synthetic Fulls via Fast Clone creates two main problems:

Metadata Friction: Updating XFS extent trees (b-trees) for thousands of reflink pointers triggers a storm of random I/O (random seek). The disk seeking latency becomes the bottleneck rather than actual data write speeds.

Raw Data Fragmentation: Over time, small blocks and scattered updates fragment the mechanical drives, degrading sequential throughput.

The Kernel 6.14+ Solution: Separating Roles and Block Sizes
The core of this architecture is leveraging native XFS subvolume separation to optimize I/O patterns according to the underlying media characteristics:

Fast Media (SSD/NVMe) -> Handles Small & Random I/O

Journaling (logdev) and Metadata: All reflink pointer updates, extent tree modifications, and directory lookups run on sub-millisecond SSD/NVMe latency.

Custom Block Allocation: Small writes and metadata structures never touch or fragment the capacity tier. The SSD stays 100% focused on absorbing high-frequency small-block operations.

Mechanical Media (HDD) -> Continuous & Sequential Flow (rtdev)

Large Block Allocation (extsize): In Kernel 6.14+, you can format the rtdev with large extent sizes (e.g., 256 KiB, 512 KiB, or 1 MiB).

Guaranteed Contiguity: XFS enforces that raw backup data written to the HDDs is allocated in contiguous blocks. The mechanical disk head performs strictly sequential reads and writes—maximizing MB/s throughput without head thrashing.

Practical Configuration Example (Kernel 6.14+)
Using updated xfsprogs and Kernel 6.14+, formatting and mounting the volume looks like this:

Formatting roles with large extents on the rtdev (HDDs):
mkfs.xfs -l logdev=/dev/vg_repo/lv_nvme_log,size=10G -r rtdev=/dev/vg_repo/lv_hdd_array,extsize=512k -m reflink=1,crc=1 /dev/vg_repo/lv_nvme_data

Mounting and assigning the subvolumes:
mount -o logdev=/dev/vg_repo/lv_nvme_log,rtdev=/dev/vg_repo/lv_hdd_array /dev/vg_repo/lv_nvme_data /mnt/veeam_repository

Setting the realtime flag on the Veeam backup directory:
xfs_io -c "chattr +t" /mnt/veeam_repository/backups

Questions for Community Discussion
Kernel 6.14+ Real-World Testing: Has anyone deployed a repository using Kernel 6.14+ with the new reflink support on rtdev in lab or production environments?

Looking forward to hearing your thoughts and experiences!