Xinnor släppte xiRAID Classic 4.4.1 den 7 oktober med stöd för kassering, så filsystemets meddelande om att ett block är ledigt passerar nu genom RAID-lagret till NVMe-enheterna under. Målet är läsintensiva NVMe SSD-enheter, som levereras med mindre reservkapacitet än blandanvändnings- eller skrivintensiva enheter och har mindre utrymme att absorbera sophämtning när data upprepade gånger skrivs och raderas. Xinnors påstående är mer konsekvent skrivprestanda under enhetens livslängd.
En läsintensiv hårddisk byter ut uthållighetsutrymme mot användbar kapacitet, vilket är anledningen till att den kostar mindre per terabyte. Inuti hårddisken landar omskriven data i ny flashminne och den gamla kopian ligger som skräp tills styrenheten återtar den. Ju mindre hårddisken vet om vilka block värden fortfarande bryr sig om, desto mer internt arbete gör den för att hitta utrymme, och det arbetet syns som skrivlatens.
Kassera stöd genom RAID-lagret
Moderna filsystem utfärdar redan förfrågningar om att markera block som inte längre innehåller användbar data; på NVMe-nivå är motsvarande kommando deallocate, och SCSI kallar det UNMAP. xiRAID Classic 4.4.1 vidarebefordrar den informationen via RAID till kompatibla NVMe-enheter, så att SSD-diskarna bakom arrayen får en korrekt bild av ledigt utrymme och kan frigöra och återanvända flashminnet enligt eget schema.
xiRAID Classic använder programvarubaserad RAID-bearbetning över CPU-kärnor samtidigt som den ansluter direkt till NVMe SSD-diskar.
”Läsintensiva NVMe-enheter har blivit en mycket övertygande grund för lagring med hög kapacitet, men att få rätt ekonomi handlar inte bara om hur många terabyte man kan installera”, säger Dmitry Livshits, VD för Xinnor. ”Lagringsstacken måste också hjälpa dessa enheter att fungera effektivt under hela sin livslängd. Med stöd för att kassera i xiRAID Classic v4.4.1 kan kunder dra full nytta av kapacitetsorienterad NVMe samtidigt som de bibehåller mer förutsägbar prestanda över tid.”
Xinnor riktar funktionen mot arbetsbelastningar som skriver, raderar och skriver om stora datamängder: HPC-filsystem, databaser, virtualiserad och containeriserad infrastruktur och säkerhetskopieringsdatabaser. Administratörer kan också köra borttagningar enligt eget schema med standardfilsystemverktyg som fstrim, vilket sätter tidpunkten för saneringen under deras kontroll.
Lystestning visar högre sekventiell skrivprestanda
Xinnor visade upp funktionen på Lustre Administrators and Developers Workshop (LAD'26) i Paris den 30 september, i en session med titeln "Maintaining Lustre Write Performance on NVMe RAID with TRIM" av senior lösningsarkitekt Daniel Landau. Testet körde Lustre 2.15.8, den nuvarande långsiktiga stabilitetsversionen, under en IO500-baserad arbetsbelastning, med regelbunden fstrim körningar som återkräver NVMe-kapacitet allt eftersom data skrevs och frigjordes.
Exempel på xiRAID-distribution för en Lustre-miljö med HA-kluster och NVMe-lagring.
I ett fokuserat sekventiellt skrivtest rapporterar Xinnor att filsystem- och applikationsnivådataflödet mer än fördubblades när xiRAID 4.4.1 kördes med korrekt fstrim hantering på Lustre OST-enheterna. Det är Xinnors eget test, så 2x är företagets siffra, och pressmeddelandet ger inga absoluta dataflödessiffror bakom den.
Uppdateringar för flervägs-RAID och klusterhantering
Utgåvan accepterar även flervägsenheter som RAID-medlemmar, och xicli hämtar kommandon för att synkronisera klusterkonfigurationer och visa mer detaljer om klustrade RAID-enheter. Enligt Xinnors installationsguide stöder xiRAID Classic 4.4.1 RHEL, AlmaLinux och Rocky Linux 8 till 10, Oracle Linux UEK 8.4, 8.6 och 9, Ubuntu 22.04, 24.04 och 26.04, samt Proxmox 8.0 till 9.2.
Amazon