Dacă ai servere cu SSD-uri NVMe și ai simțit că, deși hardware-ul poate multe, Windows tot nu pare să scoată chiar tot ce se poate, Microsoft a făcut în Windows Server 2025 o schimbare importantă: a introdus Native NVMe, adică un traseu de I/O gândit direct pentru NVMe, fără să mai trateze dispozitivele moderne ca și cum ar fi SCSI. Practic, în loc să traducă comenzile NVMe în comenzi SCSI, sistemul ocolește stratul de conversie și reduce atât latența, cât și consumul de CPU pe operațiile de disc. În spate e o reproiectare a fluxului de procesare I/O, orientată spre performanță ridicată și overhead minim.
 |
| Am testat activarea Native NVMe pe Windows 11 Pro 25H2 |
De ce contează tocmai acum? Pentru că generațiile noi de NVMe au ajuns la niveluri unde diferențele de software chiar se văd. În exemplele folosite de Microsoft, un SSD enterprise PCIe Gen5 poate urca spre 3,3 milioane IOPS, iar anumite adaptoare sau configurații pot depăși 10 milioane IOPS pe disc. Problema e că traseul tradițional bazat pe SCSI a fost construit într-o epocă a discurilor rotative și a protocoalelor precum SATA, unde ai o singură coadă de comenzi și un plafon de tipul 32 de comenzi pe coadă. NVMe, în schimb, a fost proiectat din start pentru flash și paralelism masiv, cu până la 64.000 de cozi și până la 64.000 de comenzi pe fiecare coadă, deci un model complet diferit.
Ce se schimbă în practică atunci când Windows Server 2025 folosește Native NVMe este că ajungi mai ușor la limitele reale ale hardware-ului, pentru că ai acces multi-queue fără traduceri inutile. Latența scade fiindcă dispar o parte din blocajele clasice din calea de I/O, acolo unde stivele vechi se sprijineau pe lock-uri și sincronizări în kernel pentru a gestiona resurse comune. Iar CPU-ul respiră mai bine, deoarece aceeași cantitate de I/O cere mai puține cicluri de procesor, deci rămâne putere de calcul pentru aplicații, nu pentru stocare.
Microsoft a publicat și niște cifre de laborator, ca să fie clar despre ce ordin de mărime vorbim. Într-un test simplu cu DiskSpd pe citire random 4K pe un volum NTFS, Windows Server 2025 cu Native NVMe activ a ajuns la aproximativ 80% mai multe IOPS și la circa 45% economie de CPU cycles per I/O față de Windows Server 2022. Setup-ul folosit a fost unul clar de server, cu procesor Intel dual-socket, 208 procesoare logice, 128 GB RAM și un SSD Solidigm SB5PH27X038T de 3,5 TB. Comanda exemplificată pentru reproducere este cea de mai jos, iar parametrii se pot modifica pentru scenariul tău, cu mențiunea standard că rezultatele pot varia în funcție de platformă, drivere, modelul de SSD și profilul de lucru.
diskspd.exe -b4k -r -Su -t8 -L -o32 -W10 -d30 testfile1.dat > output.dat
Unde se vede cel mai ușor diferența nu e doar în benchmark-uri, ci în zonele unde stocarea e blocajul. Pentru SQL Server și OLTP, ideea e simplă: timpi de tranzacție mai mici și tail latency mai bun când ai amestec de citiri și scrieri. Pentru Hyper-V și virtualizare, contează la pornirea VM-urilor, la checkpoint-uri și la migrare, mai ales când ai multe mașini care lovesc același subsistem de stocare. La file servere rapide, apar îmbunătățiri atât la transferuri de fișiere mari, cât și la operații de metadate, gen copiere, backup, restore. Iar pentru AI, ML și analytics, câștigul tipic e acces mai rapid și mai predictibil la seturi mari de date, cu timpi mai mici pentru ETL, shuffle și I/O de tip scratch sau cache.
Partea importantă este că funcția este disponibilă în regim opțional și rămâne dezactivată implicit, cel puțin în modelul de livrare de acum. Concret, Microsoft spune că ai nevoie de actualizarea cumulativă din octombrie pentru Windows Server 2025 sau una mai nouă, după care activezi Native NVMe manual.
Înainte să activezi orice, merită verificat un detaliu care poate face diferența între câștig vizibil și zero schimbare: SSD-urile trebuie să folosească driverul Microsoft din sistem, StorNVMe.sys. Dacă ai driver de la vendor, e posibil să nu vezi diferențe, fiindcă tocmai traseul nativ din Windows e cel care se schimbă.
Cum activezi Native NVMe
Activarea prin PoweShell (ca administrator), după ce ai instalat cel mai noi cumulative update relevant, arată așa, rulat cu drepturi de administrator (apăsați ENTER după copy-paste la fiecare comanda, altfel va ignora ultima linie din fiecare set de comenzi):
Pe Windows Server
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies\Microsoft\FeatureManagement\Overrides /v 1176759950 /t REG_DWORD /d 1 /f
Alternativ, există și o variantă cu un MSI de politici de grup care adaugă politica aferentă, după care o activezi din editorul de politici locale, pe traseul unde apare și referința la KB5066835 și Feature Preview.
Pe Windows 11
# FeatureManagement Overrides
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies\Microsoft\FeatureManagement\Overrides" /v 735209102 /t REG_DWORD /d 1 /f
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies\Microsoft\FeatureManagement\Overrides" /v 1853569164 /t REG_DWORD /d 1 /f
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies\Microsoft\FeatureManagement\Overrides" /v 156965516 /t REG_DWORD /d 1 /f
# SafeBoot Network: default value
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SafeBoot\Network\{75416E63-5912-4DFA-AE8F-3EFACCAFFB14}" /ve /t REG_SZ /d "Storage Disks" /f
# SafeBoot Minimal: default value
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SafeBoot\Minimal\{75416E63-5912-4DFA-AE8F-3EFACCAFFB14}" /ve /t REG_SZ /d "Storage Disks" /f
- În Device Manager trebuie să vezi NVMe-urile sub categoria „Storage disks”. Asta este chiar verificarea recomandată de Microsoft pentru Native NVMe în Windows Server 2025. Dacă apare tot la Disk drives și nu la Storage disks, poate fi fie OFF, fie nu s-a aplicat complet în sistemul tău.
- În Driver Details pentru discul NVMe, ar trebui să apară driverul de disc NVMe (de exemplu nvmedisk.sys) în loc să rămână doar pe traseul clasic unde vezi disk.sys ca disc generic. Comunitățile care au testat activarea (inclusiv pe Windows 11, neoficial) menționează explicit schimbarea asta ca semn că a comutat pe noua cale.
Ce îți recomand să faci acum, concret, să verifici dacă e activ: deschide Device Manager, caută categoria „Storage disks”. Dacă nu există deloc, foarte probabil nu ai comutat pe Native NVMe (sau nu e suportat în build-ul tău / nu s-a aplicat corect). Dacă există, intră pe discul tău, tab-ul Driver, apoi Driver Details și vezi dacă apare nvmedisk.sys.
Eventual verifică si în PowerShell, după restartul computerului / laptopului:
reg query "HKLM\SYSTEM\CurrentControlSet\Policies\Microsoft\FeatureManagement\Overrides" /v 735209102
reg query "HKLM\SYSTEM\CurrentControlSet\Policies\Microsoft\FeatureManagement\Overrides" /v 1853569164
reg query "HKLM\SYSTEM\CurrentControlSet\Policies\Microsoft\FeatureManagement\Overrides" /v 156965516
reg query "HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Network\{75416E63-5912-4DFA-AE8F-3EFACCAFFB14}" /ve
reg query "HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Minimal\{75416E63-5912-4DFA-AE8F-3EFACCAFFB14}" /ve
Ca să vezi dacă merită în mediul tău, abordarea corectă este să-ți faci o bază de comparație înainte, apoi să măsori după. Microsoft indică Performance Monitor și Windows Admin Center pentru monitorizare, iar pentru o verificare rapidă a IOPS în PerfMon poți urmări Physical Disk, contorul Disk Transfers/sec pe instanța corespunzătoare discului NVMe, în timp ce rulezi un workload sintetic cu DiskSpd. Ideea este să compari direct valorile înainte și după și să te uiți nu doar la IOPS, ci și la încărcarea CPU și la latențe, pentru că acolo apare de obicei câștigul real.
Un context util, ca să nu se înțeleagă greșit, este că acest tip de cale NVMe nativă există de ani buni în alte ecosisteme, iar Microsoft recuperează acum teren în Windows Server, cu accent pe a scoate mai mult din hardware-ul NVMe de ultimă generație. Totuși, beneficiul exact depinde de profilul de lucru și de compatibilitatea platformei, deci merită tratat ca o schimbare care se validează, nu ca un comutator magic care ajută orice scenariu.
Și încă un detaliu pe care îl văd deja prin discuții: deși se poate forța activarea mecanismului și pe Windows 11, Microsoft spune că suportul oficial pentru Native NVMe, în forma aceasta, este pentru Windows Server 2025, cu update-ul din octombrie sau mai nou.
Daca vrei sa anulezi modificările, rulezi asta în PoweShell (tot ca Adminstrator):
# 1) Șterge valorile din FeatureManagement\Overrides
reg delete "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies\Microsoft\FeatureManagement\Overrides" /v 735209102 /f
reg delete "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies\Microsoft\FeatureManagement\Overrides" /v 1853569164 /f
reg delete "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies\Microsoft\FeatureManagement\Overrides" /v 156965516 /f
# 2) Șterge cheile SafeBoot adăugate
reg delete "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SafeBoot\Network\{75416E63-5912-4DFA-AE8F-3EFACCAFFB14}" /f
reg delete "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SafeBoot\Minimal\{75416E63-5912-4DFA-AE8F-3EFACCAFFB14}" /f
Cum faci comparație
Ca să obții o comparație corectă „înainte” vs „după”, trebuie să rulezi exact aceleași teste, în aceleași condiții, după un restart între schimbări. Mai jos ai un set minim, dar complet, care reflectă exact scenariul pentru care se discută Native NVMe (4K random read, multi-thread, QD mare, fără cache OS).
DiskSpd se descarcă oficial de la Microsoft de pe GitHub, din secțiunea Releases (este un ZIP cu diskspd.exe). Cea mai sigură metodă: Deschide repository-ul oficial Microsoft DiskSpd. Intră în Releases și descarcă arhiva „DiskSpd.ZIP” (de obicei ultima versiune). Dezarhivează într-un folder, de exemplu D:\DiskSpd\ sau pui fișierul executabil diskspd.exe, precum si diskspd.pdb, chiar direct in rădăcina D:, cum am procedat eu (trebuie sa modifici comenzile de testare de mai jos cu calea corecta unde l-ai pus la tine, daca nu il pui direct pe D:). Rulează diskspd.exe din acel folder (sau folosește calea completă în comenzi).
Condiții recomandate (ca să reduci variațiile)
Laptop la priză.
Închide aplicații mari (browser cu multe taburi, sync, backup).
Ideal, setează planul de energie pe High performance înainte de test și îl lași la fel pentru ambele runde.
Comanda pentru High performance (dacă există pe sistem):
powercfg /S SCHEME_MIN
Dacă nu merge, rulează powercfg /L ca să vezi GUID-urile disponibile.
Pasul 0: pregătește fișierul de test o singură dată (nu-l recrea între runde)
Folosește un fișier mai mare decât RAM-ul “util” (pe laptop, 20–50 GB e de obicei ok dacă ai spațiu). Poate fi folosit si10 GB, care poate fi suficient deoarece vei rula cu -Su (unbuffered), dar e preferabil 20 GB pentru consistență.
Creează folder și fișier (o singură dată):
mkdir D:\diskspdtest -ErrorAction SilentlyContinue
# Creează un fișier de 20GB prin scriere secvențială (rapid și stabil)
D:\diskspd.exe -c20G -b1M -s -o1 -t1 -w100 -d30 D:\diskspdtest\testfile.dat
Important: de aici înainte, la testele de benchmark NU mai folosi -c, ca să nu recreezi fișierul și să nu-ți schimbi condițiile.
Setul de teste “corect” (pentru comparație)
Eu aș rula două teste:
A) 4K random read, t8, o32, fără cache software
B) 4K random read, t16, o32, fără cache software
Comenzile sunt:
# A) 4K random read, 8 thread, QD32, unbuffered, warmup 10s, durata 30s
D:\diskspd.exe -b4k -r -Su -t8 -o32 -W10 -d30 -L D:\diskspdtest\testfile.dat
# B) 4K random read, 16 thread, QD32, unbuffered, warmup 10s, durata 30s
D:\diskspd.exe -b4k -r -Su -t16 -o32 -W10 -d30 -L D:\diskspdtest\testfile.dat
Ca să fie ușor de comparat, salvează output-ul în fișiere:
D:\diskspd.exe -b4k -r -Su -t8 -o32 -W10 -d30 -L D:\diskspdtest\testfile.dat > D:\diskspdtest\OFF_4k_rr_t8_o32_run1.txt
D:\diskspd.exe -b4k -r -Su -t16 -o32 -W10 -d30 -L D:\diskspdtest\testfile.dat > D:\diskspdtest\OFF_4k_rr_t16_o32_run1.txt
De câte ori să rulezi
Rulează de 3 ori fiecare test și folosește mediana (nu “cel mai bun”). Asta reduce fluctuațiile normale de scheduler, temperatură, background tasks.
Cel mai simplu în PowerShell, automat:
# OFF (înainte de a activa Native NVMe)
for ($i=1; $i -le 3; $i++) {
D:\diskspd.exe -b4k -r -Su -t8 -o32 -W10 -d30 -L D:\diskspdtest\testfile.dat > "D:\diskspdtest\OFF_4k_rr_t8_o32_run$i.txt"
Start-Sleep -Seconds 15
D:\diskspd.exe -b4k -r -Su -t16 -o32 -W10 -d30 -L D:\diskspdtest\testfile.dat > "D:\diskspdtest\OFF_4k_rr_t16_o32_run$i.txt"
Start-Sleep -Seconds 15
}
Așteaptă 10 minute, sa ruleze testele (se termină după ce apar in folder toate 6 fișierele OFF_4k_rr_t8_o32_run1 - 3.txt si OFF_4k_rr_t16_o32_run1 - 3.txt).
După ce termini OFF:
Activezi Native NVMe (comenzile menționate anterior)
Restart obligatoriu.
Rulezi exact aceleași 3 runde, dar cu prefix ON:
# ON (după activare + restart)
for ($i=1; $i -le 3; $i++) {
D:\diskspd.exe -b4k -r -Su -t8 -o32 -W10 -d30 -L D:\diskspdtest\testfile.dat > "D:\diskspdtest\ON_4k_rr_t8_o32_run$i.txt"
Start-Sleep -Seconds 15
D:\diskspd.exe -b4k -r -Su -t16 -o32 -W10 -d30 -L D:\diskspdtest\testfile.dat > "D:\diskspdtest\ON_4k_rr_t16_o32_run$i.txt"
Start-Sleep -Seconds 15
}
Așteaptă 10 minute, să ruleze testele (la fel, se termină după ce apar în folder toate 6 fișierele ON_4k_rr_t8_o32_run1 - 3.txt si ON_4k_rr_t16_o32_run1 - 3.txt).
După ce termini setul ON:
Cum compari rapid rezultatele (fără să citești toate fișierele)
În fiecare fișier DiskSpd, te interesează în primul rând linia „total:” din secțiunea Total IO (are MiB/s și I/O per s). Poți face o comparație relevantă așa (copy-paste comenzile de mai jos in PowerShell si apoi apeși ENTER):
$ErrorActionPreference = "Stop"
function Get-Median([double[]]$values) {
$sorted = $values | Sort-Object
$n = $sorted.Count
if ($n -eq 0) { return [double]::NaN }
if ($n % 2 -eq 1) { return [double]$sorted[[int]($n/2)] }
return ([double]$sorted[($n/2)-1] + [double]$sorted[$n/2]) / 2
}
function Parse-TotalLine($line) {
$parts = ($line -split '\|') | ForEach-Object { $_.Trim() }
if ($parts.Count -lt 4) { return $null }
[pscustomobject]@{
MiBs = [double]$parts[2]
IOPS = [double]$parts[3]
}
}
function Get-FirstNonZeroTotal($file) {
$totals = Select-String -Path $file -Pattern '^total:' -ErrorAction SilentlyContinue
foreach ($t in $totals) {
$p = Parse-TotalLine $t.Line
if ($p -and $p.IOPS -gt 0) { return $p }
}
return $null
}
function Summarize-Change([double]$offVal, [double]$onVal, [string]$label, [string]$unit) {
$delta = $onVal - $offVal
$pct = if ($offVal -ne 0) { ($delta / $offVal) * 100 } else { 0 }
$deltaR = [math]::Round($delta, 2)
$pctR = [math]::Round($pct, 2)
$offR = [math]::Round($offVal, 2)
$onR = [math]::Round($onVal, 2)
if ($pctR -gt 0.5) {
return ("{0} a crescut cu {1}% (+{2} {3}) [OFF {4} → ON {5}]" -f $label, $pctR, $deltaR, $unit, $offR, $onR)
} elseif ($pctR -lt -0.5) {
return ("{0} a scăzut cu {1}% ({2} {3}) [OFF {4} → ON {5}]" -f $label, [math]::Abs($pctR), $deltaR, $unit, $offR, $onR)
} else {
return ("{0} este aproape identic (≈0%) [OFF {1} → ON {2}]" -f $label, $offR, $onR)
}
}
$tests = @(
@{ Name = "4K random read t8 o32"; Off = "D:\diskspdtest\OFF_4k_rr_t8_o32_run*.txt"; On = "D:\diskspdtest\ON_4k_rr_t8_o32_run*.txt" },
@{ Name = "4K random read t16 o32"; Off = "D:\diskspdtest\OFF_4k_rr_t16_o32_run*.txt"; On = "D:\diskspdtest\ON_4k_rr_t16_o32_run*.txt" }
)
foreach ($test in $tests) {
$offFiles = Get-ChildItem $test.Off -ErrorAction SilentlyContinue
$onFiles = Get-ChildItem $test.On -ErrorAction SilentlyContinue
if (-not $offFiles -or -not $onFiles) {
Write-Host ("Atenție: lipsesc fișiere pentru '{0}'." -f $test.Name) -ForegroundColor Yellow
continue
}
$offVals = foreach ($f in $offFiles) { $p = Get-FirstNonZeroTotal $f.FullName; if ($p) { $p } }
$onVals = foreach ($f in $onFiles) { $p = Get-FirstNonZeroTotal $f.FullName; if ($p) { $p } }
if (-not $offVals -or -not $onVals) {
Write-Host ("Atenție: nu pot extrage 'total:' valid pentru '{0}'." -f $test.Name) -ForegroundColor Yellow
continue
}
$offIOPS = @($offVals | Select-Object -ExpandProperty IOPS)
$onIOPS = @($onVals | Select-Object -ExpandProperty IOPS)
$offMiBs = @($offVals | Select-Object -ExpandProperty MiBs)
$onMiBs = @($onVals | Select-Object -ExpandProperty MiBs)
$offIOPS_Med = Get-Median $offIOPS
$onIOPS_Med = Get-Median $onIOPS
$offMiBs_Med = Get-Median $offMiBs
$onMiBs_Med = Get-Median $onMiBs
Write-Host ""
Write-Host ("=== {0} (mediană, {1} runde OFF / {2} runde ON) ===" -f $test.Name, $offFiles.Count, $onFiles.Count) -ForegroundColor Cyan
Write-Host (Summarize-Change $offIOPS_Med $onIOPS_Med "IOPS" "IOPS")
Write-Host (Summarize-Change $offMiBs_Med $onMiBs_Med "Viteza (MiB/s)" "MiB/s")
}
IOPS (I/O per s) la 4K random read, t16/o32 este indicatorul principal. În testele mele pe Windows 11 Pro 25H2, cu Native NVMe activat, a fost mai bun cu aproximativ 46%, respectiv 6%
Cum e afectată viteza de citire și scriere?
Am făcut cateva teste cu 1GB si 10GB cu utilitarul AS SSD Benchmark, și din capturile de mai jos se vede clar că scrierea secvențială a ieșit mai mică pe ON, în timp ce alte rezultate (în special random/multi-thread) au crescut.
Ce arată concret testele mele
Pentru 1 GB:
Seq Read: OFF 4888,85 MB/s → ON 4989,78 MB/s (aprox. +2,1%)
Seq Write: OFF 2795,34 MB/s → ON 2038,85 MB/s (aprox. −27,1%)
Pentru 10 GB:
Seq Read: OFF 4888,57 MB/s → ON 5044,74 MB/s (aprox. +3,2%)
Seq Write: OFF 2773,79 MB/s → ON 2205,78 MB/s (aprox. −20,5%)
În același timp, la random 4K cu multe thread-uri (4K-64Thrd) am creșteri mai mari la citire (și uneori și la scriere), ceea ce este exact genul de zonă unde „native NVMe” ar trebui să ajute (multi-queue, cale mai „subțire” prin kernel).
Este posibil să fie „normal” ca Seq Write să scadă cu Native NVMe? Da, este posibil. Sunt două idei importante aici:
Native NVMe e gândit să reducă overhead-ul și să scaleze mai bine pe I/O paralel (IOPS, cozi multiple). La secvențial mare, de multe ori limita nu este stack-ul de I/O din Windows, ci SSD-ul (controller, cache intern, temperatură, SLC cache, firmware). În scenariul acesta, câștigul din stack poate fi mic, iar în anumite combinații poate apărea o mică penalizare.
Scrierea secvențială este cea mai sensibilă la condițiile de test. Poate varia mult de la o rundă la alta din cauze care nu au legătură directă cu ON/OFF
Scăderea de 20–27% la Seq Write este suficient de mare încât merită verificată printr-un A/B mai controlat, ca să știm dacă e efect real și repetabil sau doar o diferență de stare (cache/temperatură).
Seq Write mai mic pe ON (cam în același ordin de mărime), pentru workload-ul de „copiere/scriere secvențială” e posibil ca ON să nu fie avantajos pe sistemul/SSD/driverul meu.
Ce înseamnă asta în viața reală? Dacă tu faci multă copiere de fișiere mari (video, arhive mari) și vrei maxim de MB/s la scriere, rezultatul Seq Write contează.
Dacă tu rulezi multe operații simultane, multe fișiere mici, VM-uri, baze de date, cache-uri, atunci îmbunătățirile la 4K-64Thrd și, în general, la random/multi-queue sunt mai relevante decât Seq Write.
Dacă vrei în practică un Windows un pic mai vioi, multe taburi, Photoshop, filme), câștigurile relevante sunt în principal la latență și la I/O random (mai ales 4K, cozi multiple), nu la scriere secvențială de tip copy de fișiere mari. Din testele mele se vede exact tiparul acesta: citirea secvențială e similară sau ușor mai bună pe ON, iar random/multi-thread (4K-64Thrd) crește mult pe ON, în timp ce scrierea secvențială a scăzut în runda respectivă.
Vrei Windows „mai rapid” (deschidere aplicații, Start, Explorer, cache-uri, update-uri mici)? Aici contează în primul rând latența și random read. Un câștig la 4K și la acces concurent ajută mai mult decât „Seq Write”. Deci, dacă ON îți crește 4K/multi-thread și nu produce instabilitate, în principiu e în direcția bună pentru senzația de viteză.
Browser cu multe taburi? În mod normal, browserul e limitat de RAM și CPU, nu de SSD. SSD-ul intră în joc când sistemul începe să page-uiască (pagefile) din lipsă de RAM, browserul scrie/recitește cache sau profile sau ai multe procese și se face I/O concurent În aceste situații, iarăși contează random și latența mai mult decât scriere secvențială.
Photoshop folosește scratch disk (mai ales când RAM-ul nu ajunge sau când lucrezi cu fișiere mari). Scratch-ul este un mix de I/O, nu doar secvențial. În general, îmbunătățirile la cozi multiple și random pot ajuta. O scădere la Seq Write nu înseamnă automat că Photoshop va fi mai lent; efectul real depinde de cât de des ajungi în scratch și ce pattern are proiectul tău.
Filme (local sau streaming)? Pentru redare video, orice NVMe modern e „overkill”. Aici contează mai mult decodarea (CPU/GPU), player-ul și, dacă e streaming, rețeaua. SSD-ul nu e factorul limită, iar diferențele ON/OFF nu ar trebui să se simtă.
De ce îți poate scădea Seq Write pe ON, dar totuși experiența să fie mai bună? Scrierea secvențială e foarte sensibilă la starea SSD-ului (SLC cache, temperatură, fundal). Native NVMe țintește în principal eficiența și scalarea I/O concurrent (random, multi-queue). O scădere la „Seq Write” nu te lovește aproape deloc în browsing/multe taburi sau redare filme; te-ar afecta mai mult dacă faci des copieri mari de zeci/sute de GB sau exporturi video masive.
Dacă sistemul e stabil și nu ai probleme ciudate (BSOD, freeze, device reset): aș lăsa ON activ pentru scenariile Windows + multitasking + Photoshop, fiindcă rezultatele care contează pentru senzația de viteză sunt exact cele care tind să crească.
Dacă „Windows se mișcă mai bine” cu ON și nu ai erori/instabilitate, pentru jocuri aș lăsa ON activ. Nu te aștepta la FPS mai mare, dar poți obține timpi de încărcare ușor mai buni și, eventual, mai puține spike-uri de I/O în open-world.
Dacă observi ceva concret mai rău în utilizare (ex. copiere fișiere mari vizibil mai lentă constant, nu doar în benchmark) și asta te deranjează, atunci merită să revii pe OFF sau să păstrezi ON doar dacă beneficiezi real.
