Otroligt långsam disk usages när det kommer till steam!

Kör Samsung Magician och kolla om det finns någon firmwareuppdatering till disken.

Varför tänker du att det ens är något fel? Är det inte bara hastigheten som din dator i största allmänhet kan utföra arbetet i?

Skojar du eller? Den estimerar att det ska ta >2d att applicera en patch. Iofs en sjukt stor patch, men 2 dagar ska det ju inte ta.

Jag hade också kollat om det är något fel med disken.

Klart att det inte ska ta, men det betyder ju inte att det direkt behöver vara disken? Tänkte om personen har multipla diskar och får bra prestanda på de andra eller liknande orsaker till att tror att det just är disken som är problemet.

Hade samma SSD som helt plötsligt blev riktigt seg. Löste sig med firmware-upd. Lite märkligt då det kändes som den tappade 75% av prestandan över natten.

Vad ligger CPU användningen på? Steam gjorde en förändring i hur patchar appliceras för ett tag sedan (för att spara data) som gjorde patchning olidligt långsamt även på nvme-ssd.

Hittade det här citatet på steams forum:

"For some reason my update is patching through a drive that the game isn't even downloaded on. I have it downloaded on an M.2 SSD and its patching it through an external hard drive that I use for recordings and such."

Har du provat att köra en benchmark på disken?

Har du kollat i taskmanager och på disk om disken är 100 % 'busy' och kölängden på olika diskkommandon verka ha höga värden - om inte och en bit under 100% och kön för diskkommandon bara på enstaka enheter är det troligen inte disken som sölar.

Jag skulle också prova att stänga av defender (MS-antivirus program) eller använda AVS av annat tillverkare tillfälligt på den disken som Steam bearbetar och patchar filerna i - andra tester där jag provade att göra 10 miljoner småfiler så är defender en fruktansvärt stor resursförbrukare som lätt kan halvera takten.

Jag gissar också att patchningen är enkeltrådat, har mycket hashning och kompression vilket innebär att det rullar igenom filerna med rullande hash och sedan byter ut de bitar som patchfilen säger behöver ändras[1] vilket gör att om det bara är en kärna som gör jobbet så går det inte så fort som man kanske är van med multi-tråd program.

[1] 'rsync' som används inom Unixvärlden för synkning av filträd och backup använder just detta för att se skillnad även inom filkropp på filer mellan källa och mål och bara skickar datat som faktiskt skiljer sig, och med '--inplace' så modifieras den befintliga filen i målet utan att det görs någon temporär kopia som det annars normalt gör och sedan byter plats med den äldre filen och den äldre filen sedan raderas.