Xinnor released xiRAID Classic 4.4.1 on October 7 with discard support, so the file system’s notice that a block is free now passes through the RAID layer to the NVMe drives underneath. The target is read-intensive NVMe SSDs, which ship with less spare capacity than mixed-use or write-intensive drives and have less room to absorb garbage collection when data is repeatedly written and deleted. Xinnor’s claim is more consistent write performance over the life of the drive.
A read-intensive drive trades endurance headroom for usable capacity, which is why it costs less per terabyte. Inside the drive, rewritten data lands in fresh flash and the old copy sits as garbage until the controller reclaims it. The less the drive knows about which blocks the host still cares about, the more internal work it does to find space, and that work shows up as write latency.
Discard Support Through the RAID Layer
Modern file systems already issue discard requests to mark blocks that no longer hold useful data; at the NVMe level the equivalent command is deallocate, and SCSI calls it UNMAP. xiRAID Classic 4.4.1 forwards that information through the RAID to compatible NVMe drives, so the SSDs behind the array get an accurate picture of free space and can reclaim and reuse flash on their own schedule.
xiRAID Classic uses software-based RAID processing across CPU cores while connecting directly to NVMe SSDs.
“Read-intensive NVMe drives have become a very compelling foundation for high-capacity storage, but getting the economics right is not only about how many terabytes you can install,” said Dmitry Livshits, CEO of Xinnor. “The storage stack also needs to help those drives operate efficiently throughout their service life. With discard support in xiRAID Classic v4.4.1, customers can take fuller advantage of capacity-oriented NVMe while maintaining more predictable performance over time.”
Xinnor points the feature at workloads that write, delete, and rewrite large volumes of data: HPC file systems, databases, virtualized and containerized infrastructure, and backup repositories. Administrators can also run discard on their own schedule with standard file-system tools such as fstrim, which puts the timing of the cleanup under their control.
Lustre Testing Shows Higher Sequential Write Performance
Xinnor showed the feature at the Lustre Administrators and Developers Workshop (LAD’26) in Paris on September 30, in a session titled “Maintaining Lustre Write Performance on NVMe RAID with TRIM” from senior solution architect Daniel Landau. The test ran Lustre 2.15.8, the current long-term stability release, under an IO500-based workload, with regular fstrim runs reclaiming NVMe capacity as data was written and freed.
Example xiRAID deployment for a Lustre environment using HA clusters and NVMe storage.
In a focused sequential-write test, Xinnor reports that filesystem and application-level throughput more than doubled when xiRAID 4.4.1 ran with proper fstrim handling on the Lustre OST devices. That is Xinnor’s own test, so the 2x is the company’s figure, and the release gives no absolute throughput numbers behind it.
Multipath RAID and Cluster Management Updates
The release also accepts multipath devices as RAID members, and xicli picks up commands to synchronize cluster configurations and show more detail on clustered RAIDs. According to Xinnor’s installation guide, xiRAID Classic 4.4.1 supports RHEL, AlmaLinux, and Rocky Linux 8 through 10, Oracle Linux UEK 8.4, 8.6, and 9, Ubuntu 22.04, 24.04, and 26.04, and Proxmox 8.0 through 9.2.
Amazon