Den 15 december 2025 meddelade Microsoft att Windows Server 2025 äntligen skulle använda NVMe-standarden som en del av sin lagringsarkitektur. NVMe-lagring har dock varit ett populärt lagringsformat på servrar, företagsarbetsstationer och konsumentdatorer i många år, med inbyggd operativsystemkompatibilitet sedan Windows Server 2012 R2 och Windows 8.1. Med detta i åtanke kanske ett tillkännagivande om "nativt" NVMe-stöd inte verkar viktigt eller ens nyhetsvärt, men vi lovar att det finns mer i detta än vad som syns vid första anblicken.
Vad betyder ens "Native NVMe"?
I tidigare versioner av Windows konsument- och serverutgåvor för lagringsstackar översattes kommandon som användes för att läsa och skriva data, oavsett den underliggande hårdvarans protokoll, alltid till SCSI-kommandon. SCSI-standarden (Small Computer System Interface) går tillbaka till början av 1980-talet och utformades för att ansluta kringutrustning och lagringsenheter till datorer (Storage Networking Industry Association, nd). Det är grunden för flera moderna lagringsprotokoll som används för olika arbetsbelastningar, inklusive nätverksanslutna protokoll som iSCSI (Internet Small Computer System Interface) och FCP (Fibre Channel Protocol), och lokala lagringsgränssnitt som SAS (Serial Attached SCSI) och UASP (USB Attached SCSI).
Gamla vägen
Genom att konvertera olika protokoll till SCSI-kommandon förenade Microsoft lagringskommandon på högre nivåer i operativsystemet. Ändå offrade man många av skalbarhets- och prestandaförbättringarna hos moderna lagringsarkitekturer. Den gamla vägen för I/O-operationer såg ut så här:
- Läs- och skrivoperationer sker i den övre lagringsstacken på filsystemnivå.
- Kommandon skickas vidare till Disk.sys-drivrutinen.
- Disk.sys översätter generiska lagringskommandon till SCSI-kommandon.
- Storport tar emot SCSI-kommandona och skickar dem till lämplig Miniport-drivrutin (t.ex. StorAHCI.sys för SATA-enheter).
- Motsvarande Miniport-drivrutin kommunicerar direkt med lagringsenheten och översätter den igen till lämpligt lagringskommandoformat.
Andra SCSI-konventioner, såsom LUN:er (logiska enhetsnummer) som används för att identifiera datapartitioner på en lagringsenhet, överfördes till Windows lagringsstack, även om nyare koncept som NVMe-namnrymder har funnits ett bra tag (Hands, Worley och Lakhveer Kaur, nd).
Den nya standarden
Microsofts senaste lagringsarkitektur för Windows Server 2025 möjliggör nya funktioner i Storport och ersätter Disk.sys med NVMeDisk.sys, vilket ger ett skalbart, framtidsklart och högpresterande ramverk.
- Läs- och skrivoperationer sker i den övre lagringsstacken på filsystemnivå.
- Kommandon skickas direkt från NVMeDisk.sys till den nya StorMQ-koden i Storport.
- StorMQ genererar lämpliga NVMe-kommandon (eller annan lagringstyp) för varje läs- och skrivoperation och skickar dem direkt till själva hårdvaran.
(Bild från Scott Lees presentation vid SNIA Developer Conference den 16 september 2025)
Denna nya standard för enhetsdrift på Windows Server 2025 eliminerar ett lager av översättning och integrerar sig helt med lagringskommandoköerna på NVMe-, RAID- och HBA-enheter. Att effektivisera Windows-lagringssystemet erbjuder också ytterligare fördelar, såsom minskad CPU-resursanvändning genom att eliminera onödig översättning av lagringskommandon och förbättrad användning av logiska processorer. Den nya arkitekturen använder andra NVMe-specifikationer, såsom NVMe-namnrymder och plug-and-play-stöd. Den gör det möjligt att skapa och "ansluta" leverantörs- eller enhetstypspecifika lagrings-Miniport-drivrutiner till Windows för ökad kompatibilitet och prestanda med nya klasser av lagringsenheter (Lee, SNIA SDC 2025 – Storage Multi-Queue on Windows, 2025).
Redo att testa?
I sin presentation på SNIA Developer Conference den 16 september 2025 avslöjade Scott Lee att Microsoft redan arbetade nära leverantörer för att utveckla nya drivrutiner för enheter som RAID-kort och HBA:er. Detta tyder på att förbättringarna av StorMQ kommer snart eller kanske redan är aktiverade på många lagringsenheter. Funktionen tillkännagavs som allmänt tillgänglig i december förra året, men den nya lagringsstacken är endast aktiverad som ett alternativ, vilket kräver att en registernyckel läggs till. Du kan läsa stegen för att aktivera den i Microsofts artikel om inbyggda NVMe-tillkännagivande.
Varning: Felaktig ändring av registret kan orsaka allvarliga problem, så se till att testa detta på en icke-kritisk server först. Flera användare som aktiverade den här funktionen rapporterade problem med NVMe-enheter med deduplicering aktiverad. Även om en officiell korrigering från Microsoft kommer snart, fortsätter du på egen risk!
Testa nativt NVMe på Windows Server 2025
Vår testplattform för att utvärdera nativ NVMe på Windows Server 2025 (OS Build 26100.32370) innehöll en server med dubbla SP5-sockets utrustad med två 128-kärniga AMD EPYC 9754-processorer. Vid sidan av flerkärniga processorer fanns lika imponerande 768 GB DDR5-minne med en hastighet av 4800 MT/s.
Obs: Enligt Microsofts Yash Shekar har en interimistisk förbättring, som inte är relaterad till native NVMe, redan släppts för Windows Server 2025, vilket kan ha gett ytterligare förbättringar för den icke-native lagringsstacken, vilket minskat den potentiella skillnaden mellan resultaten.
För att utvärdera potentialen hos den nya lagringsstacken använde vi femton 30.72 TB Solidigm P5316 NVMe SSD-diskar med PCIe 4.0 i en JBOD-konfiguration. En viktig anmärkning är att Solidigm P5316 har en indirektionsenhetsstorlek på 64 kilobyte, vilket innebär att skrivresultaten för mindre storlekar (som 4K-tester) ofta är sämre än väntat. Med tanke på denna större indirektionsenhet körde vi FIO-riktmärken med läs- och skrivtester för slumpmässig 4K, slumpmässig och sekventiell 64K, och sekventiell 128K för att jämföra den totala hastigheten över olika blockstorlekar. Vi övervakade också CPU-användningen under testningen för att utvärdera Microsofts påståenden om högre effektivitet.
Höjdpunkter
- Massivt ökad 4K och 64K slumpmässig läsbandbredd och IOPS
- Lägre 4K och 64K slumpmässig läsfördröjning
- Betydande minskningar av CPU-användningen för sekventiell läsning och skrivning över olika blockstorlekar
| metrisk | Slumpmässig 4K | Slumpmässig 64K | Sekventiell 64K | Sekventiell 128K | ||||
|---|---|---|---|---|---|---|---|---|
| Icke-infödd | Native | Icke-infödd | Native | Icke-infödd | Native | Icke-infödd | Native | |
| Läsa | ||||||||
| Bandbredd (GiB/s) | 6.1 | 10.058 | 74.291 | 91.165 | 35.596 | 35.623 | 86.791 | 92.562 |
| IOPS | 1,598,959 | 2,636,516 | 1,217,176 | 1,493,637 | 583,192 | 583,638 | 710,978 | 758,252 |
| Genomsnittlig latens (ms) | 0.169 | 0.104 | 0.239 | 0.207 | 0.809 | 0.812 | 0.613 | 0.608 |
| Total CPU-användning (%) | 72.67 | 74.22 | 68.44 | 65.11 | 44.89 | 37.11 | 61.56 | 49.56 |
| metrisk | Slumpmässig 4K | Slumpmässig 64K | Sekventiell 64K | Sekventiell 128K | ||||
|---|---|---|---|---|---|---|---|---|
| Icke-infödd | Native | Icke-infödd | Native | Icke-infödd | Native | Icke-infödd | Native | |
| Skriva | ||||||||
| Bandbredd (GiB/s) | 1.803 | 1.756 | 7.654 | 7.655 | 44.67 | 50.087 | 50.477 | 50.079 |
| IOPS | 472,725 | 460,383 | 125,391 | 125,406 | 731,859 | 820,603 | 413,495 | 410,232 |
| Genomsnittlig latens (ms) | 0.992 | 1.028 | 3.814 | 3.816 | 0.399 | 0.558 | 1.022 | 1.149 |
| Total CPU-användning (%) | 26.00 | 20.67 | 12.22 | 9.33 | 70.44 | 57.78 | 58.44 | 47.33 |
Analys av resultat
Med början i slumpmässiga 4K- och 64K-lästest observerade vi betydligt högre läshastigheter, med en skillnad på nästan 4 GiB/s mellan de inbyggda respektive icke-inbyggda lagringsstackarna i slumpmässig 4K-lästestet, och en ökning på nästan 16.9 GiB/s vid slumpmässig 64K-läsning. Vi såg också en hyfsad ökning av sekventiella 128K-läsoperationer, där våra tester visade en ökning av bandbredden på cirka 5.8 GiB/s.
Märkligt nog såg vi inga signifikanta ökningar i våra tester av slumpmässig eller sekventiell skrivning, med den enda anmärkningsvärda skillnaden en ökning på ungefär 5.4 GiB/s i 64K sekventiella skrivningar. De flesta av våra resultat låg inom 100 MiB/s från varandra, vilket tyder på att den nya lagringsstackens prestanda åtminstone är i linje med den gamlas i de fall där den inte förbättrades.
Eftersom dataflödet vanligtvis är korrelerat med latens observerade vi också stora minskningar i genomsnittlig latens för slumpmässig läsning för både 4K- och 64K-tester. Vi såg en minskning på 38.46 % i icke-ursprunglig slumpmässig läsning i 4K, från 0.169 millisekunder till 0.104. Slumpmässiga 64K-läsningstester hade en mindre minskning, runt 13.39 %. Latensen förändrades inte drastiskt med sekventiella läsoperationer, men slumpmässiga skriv- och sekventiella skrivoperationer visade ökningar över hela linjen, trots liknande eller högre dataflöde.
Förutom ökningen av slumpmässiga läshastigheter, avslöjade våra FIO-tester en betydande minskning av den totala CPU-användningen för sekventiella läs- och skrivoperationer på 64K och 128K. Sekventiella skrivtester visade de mest dramatiska skillnaderna, med en genomsnittlig minskning på 12.66 % CPU-användning för 64K och en nästan motsvarande minskning på 11.11 % för 128K. Det sekventiella 128K-lästestet vi utförde såg också en passande minskning på 12 % användning, men bara en minskning på 7.78 % för sekventiell 64K-läsning. En faktor att beakta är att med en tillräckligt snabb CPU kan det finnas tillfällen där båda stackarna kan nå en lagringsenhets fulla potential; därför kanske dataflödet inte ökar, men CPU-resursanvändningen skulle minska.
takeaways
Medan många av våra resultat låg inom avvikelsen mellan körningar efter att ha aktiverat den nya lagringsstacken, kunde vi bekräfta många av Microsofts påståenden, inklusive högre läsbandbredd med lägre latens och minskad CPU-användning över hela linjen. Eftersom detta är en ganska radikal förändring av deras decennier gamla Windows Server-lagringsstack, kommer Microsoft först att aktivera native NVMe som standard i Windows Server vNext. Lyckligtvis kan funktionen aktiveras på Windows Server 2025 med en snabb registerredigering eller en grupprincip, vilket gör att modiga serveradministratörer kan dra nytta av den nya stacken redan idag (efter att ha erkänt riskerna med att driftsätta den).
Vi ser fram emot att se inbyggt NVMe aktiverat som standard på Windows Server-plattformen och hoppas få se stöd från tillverkare av NVMe SSD-, RAID-kort- och HBA-enheter, som borde kunna ta Microsofts förbättringar till nästa nivå!
Referensprojekt
Hands, J., Worley, D., & Lakhveer Kaur. (nd). NVMe-namnrymder. Hämtad 30 december 2025 från NVM Express: https://nvmexpress.org/resource/nvme-namespaces/
Lee, S. (15 september 2025). SNIA SDC 2025 – Storage Multi-Queue on Windows. San Tomas, CA, USA: Storage Networking Industry Association. Hämtad 29 december 2025 från https://www.youtube.com/watch?v=dR-DWrmCba0&t
Lee, S. (16 september 2025). Storage Multi-Queue on Windows: A New Stack for High Performance Storage Hardware. Hämtad 29 december 2025 från SNIA Developer Conference: https://www.snia.org/sites/default/files/2025-10/SNIA-SDC25-Lee-Storage-Multi-Queue-On-Windows.pdf
Shekar, Y. (15 december 2025). Annonsering av Native NVMe i Windows Server 2025: Inledningen av en ny era av lagringsprestanda. (Microsoft) Hämtad 29 december 2025 från Windows Server News and Best Practices: https://techcommunity.microsoft.com/blog/windowsservernewsandbestpractices/announcing-native-nvme-in-windows-server-2025-ushering-in-a-new-era-of-storage-p/4477353
Storage Networking Industry Association. (nd). Vad är SCSI? Hämtad 30 december 2025 från Storage Networking Industry Association: https://www.snia.org/education/what-is-scsi
Amazon