To dost záleží na velikosti RAM, ale disková aktivita tam bude vždy. Desktkopvé Windows se snaží o maximálně pružnou odezvu. U typických HW konfigurací je RAM poměrně málo. Přitom při spuštění větší aplikace tu RAM potřebujete. Proto Windows drží spoustu v RAM a zároveň ve swappu. Když je pak potřeba velký kus RAM, tak se prostě zahodí to co v ní právě je, protože je to stejně i ve swappu, a použije se tam kde je v tento moment více potřeba. Píšu to zjednodušeně, ale vysvětluje to princip. Ona historicky byla RAM velmi drahá, a Windows proto pracovaly v podstatě pořád v režimu, kdy byl tenhle přístup vysoce výhodný. Představte si NT 4.0 s 16 MB RAM. A díky "pokroku" v paměťových nárocích aplikací se situace s poměrem potřebné a instalované RAM až tolik nezměnila. Jen jsme přidali cca tři řády v nárocích aplikací i velikosti RAM na typickém HW.
Linux tradičně pracoval se swappem úplně jinak. Všechno bylo pouze v RAM, a swap se prakticky nepoužíval. Teprve když bylo opravdu málo dostupné RAM, se používat masivně začal. To na jedné straně znamenalo v klidovém stavu výrazně nižší diskovou aktivitu. Na druhé straně pokud bylo potřeba větší množství RAM, například při spouštění větší aplikace, tak to mohlo vyústit ve velikou spoustu diskové aktivity, a systém z uživatelského pohledu na nějakou dobu úplně vytuhnul. Dalším problémem byl výkon dynamického linkování při zavádění procesů. Ve výsledku byl start aplikací výrazně delší. Výkon dynamického linkování se pokud vím zlepšil, a u swappování se během let opakovaně měnily algoritmy a jejich parametry. Upřímně současný stav neznám, protože dneska s Unixy už moc nedělám.
hodne zjednodusene:
RAM pamet je draha a rychla a neopotrebovava se, takze primarne ji dostanou aplikace. Pokud zbyva nejaka volna, pouzije se pro cache OS (treba diskovou cache). Pokud ji (cast) dlouhou dobu system nepouziva, odswapuje ji na disk (jak moc system swapuje, to se v linuxu da nastavit).
Jakmile pamet zacne naopak dochazet, vezme se z nejdele nepouzivane cache, a pokud cache nestaci, zacne se nejdele nepouzivana odsouvat do swapu.
Ja pouzivam linux a mam 32 GB RAM (DDR5) a swap na disk mam vypnuty. Pokial je system dobre spraveny a mas dostatok RAM tak swap na disk je uplna blbost. Pokial ma uzivatel malo RAM, tak ze by system musel swapovat disk, tak to swapovanie uzivatela nezachrani, nastalo by brutalne spomalenie a tak ci tak je upgrade RAM nevyhnutny.
Aj aj ked je swap RAM vypnuty este to neznamena ze system neuklada data na disk. Ale ak je system dobre spraveny, toto ukladanie by malo byt minimalne a nemalo by ohrozovat SSD
Ak system ohrozuje SSD, tak system je zle spraveni a nezaslusi si ho uzivatel pouzival. Ked sa pozrieme na MS a jeho windows, tak okrem SSD ma mnoho dalsich chyb, rozhodhnuti MS, nedorobenych veci a schyzofrenie tak s toho jasne vyplyva ze pouzivanie Windows je masochizmus.
Ještě to může být třeba nějakým souběhem komponent nebo driverů.
Když se zákazník neobrátí na support, tak víme jen to, co se najde na sociálních sítích. To klidně může být jeden člověk, který má z nějakého technického či jiného důvodu problém, a napíše o tom dvacetkrát pod různými jmény. Navíc žijeme v době, kdy se na základě takových postů na sociálních sítích píšou články v "solidních" médiích. A ty články pak můžou být stejný trash, jako ty posty, ze kterých vycházejí.
Videl jsem mnoho zapojeni notasu a zadnej nema separatni rizeni napajeni k M2 slotu. Vypina se to leda pri prechodu do nejakeho sleep stavu..
Ale taky jsem videl jak disky (a konkretne Phison) nezvladaji power management - a sam jsem kvuli tomu pridaval quirky do nvme driveru v linuxu.. aby to vubec chodilo v beznem desktopu. Pokud od toho nejaky gameloader OS chce poslepu slusne chovani.. toho se bohuzel nedocka :)
Zadny vyrobce dnes nema poradny technicky support - vse se zjednodusilo na RMA v zaruce (skrze distributora kde jste to koupil) a pak F**K OFF.
Vsude jsou jen "uzivatelske fora", i kdyz pod domenou brandu, tak se od toho brand distancuje.
Pomoz si sam.. nuz jak???
Napsat na takovy "support" forum je k nicemu.
Firmy neco hodlaj delat jenom kdyz jim na sockach budete delat vzruso a oni z toho - tak ti 'pomuzeme' - muzou vytriskat PR bodiky.. bohuzel to je dnesni doba.
Já mám problém když nahrávám soubory na nas že mají nulovou velikost. Děje se to občas ale už dlouho. Nevím jestli to s tím může souviset ale je to nepříjemné a musím vše kontrolovat. Nvme Samsung 950 pro. Jo a taky stahování z nasu na flešku byla instantně modrá smrt. Nevím jestli to už vyřešili.
30. 8. 2025, 07:43 editováno autorem komentáře
Běžný sw pro windows (ESET, Outlook) klidně natočí 100GB zápisů denně.
https://www.abclinuxu.cz/blog/Max_Devaine/2021/4/ssd-a-zniceni-beznym-pouzivanim-mozna-to-jde
30. 8. 2025, 10:56 editováno autorem komentáře
Windows vědí, co je pro nás dobré, co chceme dělat, jak chceme žít. Jestli si myslíme něco jiného, třeba ze na pracovním počítači s W-Pro chceme pracovat, abychom měli splněné úkoly, je to naše chyba.
A že aktualizace Windows jsou často z různých důvodu ke vzteku snad nepopře nikdo. Často může být i jednou za rok dva, když se trefí "správný" okamžik.
Stalo se mi to několikrát taky a taky jsem dospěl k závěru, že je to přehříváním. Je to SSD M.2 WD Black a stávalo se to při kopírování velkého množství (~1M) souborů na jdden zátah. Už to nedělám: - )
Někdy ve správci souborů prostě přestali být viditelné nebo přístupné některé adresáře, někdy celý disk. Po restartu se zase objevil, nicméně k nějakému poškození tam asi došlo, mám tam soubor, po jehož načtení disk spolehlivě zmizí, zase až do restartu. Od té doby zálohuju a trnu, kdy disk selže, ale zatím několik měsíců bez problému. Ve SMART není nic neobvyklého, všechno se tváří OK. Přiznám se, že spojovat to s Windows mě až doteď nenapadlo.
Nezávisle na systému, tohle málokdy probíhá úplně tiše a bez jakékoliv chybové hlášky.
Ve Windows konkrétně jsou v event logu zdroje jako např..
disk, storport, stornvme (resp. storahci u SATA), tam to chce sledovat chyby I/O operací, opakování, pokusy o reset sběrnic, když vyprší timeout atp.
Nad tím je zas filesystém, takže zdroj ntfs.. tam by byly případně vyloženě chyby (číslo. 55) při načítání po nějaké nedokončené operaci, případně by si to před pádem mohlo stěžovat na to, že nemůže zapsat žurnál.
Finálně u NVMe disků, které jsou přímo na PCIe, stojí za to koukat i po zdroji WHEA-Logger, který pak může produkovat eventy při chybách přenosu na sběrnici.
Ale jak jste říkal, tak teplota může být často problém, krom toho, že se dá při nějaké větší zátěži logovat, tak když se to začne blížit k nějakému limitu, tak to také koreluje s delší dobou odezvy až to případně začne vypadávat úplně a třeba se resetovat. Spousta SSD začne zjednodušeně řečeno throttlovat velice podobně jako např. CPU.
Ta informace o maximální délce odezev (Read, Write, Flush) od startu systému je pak dostupná buď přes perfmon nebo třeba v PowerShellu.
Takhle to třeba spojíte s daty ze SMART atributů, resp. NVMe namespace.
Get-PhysicalDisk | Get-StorageReliabilityCounter | Ft DeviceId, Wear, Temperature, ReadErrorsTotal, WriteErrorsTotal, MediaErrorsTotal, PowerOnHours, PercentageUsed, *LatencyMax -Auto
Čísla disků se dají dekódovat, když pustíte jen samotný Get-PhysicalDisk.
Ale perfmon je asi lepší pro sledování v čase, byť i tady si můžete taky udělat smyčku a přes Export-CSV appendovat např. do souboru na jiném disku.
Jinak dodatečný chladič, pokud trochu proudí vzduch ve skříni, nemusí být úplně marný.
Také jsem viděl SSD (nějaký šílený Lexar), kde pomohlo srazit rychlost z PCIe 4 na 3 (deska to uměla z BIOSu per slot). Zmizely CRC chyby a výrazně se snížila teplota..
Obecně vzato, já bych s tím, že to sem tam nezapíše data (ať už z jakéhokoliv důvodu), asi úplně nedokázal fungovat.. Zkusil bych si udělat zálohu, nebo třeba bitovou kopii disku někam vedle, pak bych udělal secure erase (třeba z nějaké utility od výrobce), abych měl výchozí stav. A pak to zkoušel šikanovat (třeba s větším množství náhodných zápisů přes fio, diskspd, CrystalDisk), dokud případně nedojde k chybě.. a při tom to monitoroval, upravoval chlazení, nastavení atp. Jinak ty SanDisk/WD Blacky by měly mít 5 let záruku, jestli se nepletu.
Ahoj. Ne nutně, trochu záleží na situaci a konkrétním problému, ale pokud to nesletí hned do bluescreenu, tak je tam krátký buffer v paměti v kterém by těch pár posledních eventů mohlo být vidět (bude to samozřejmě blít spousty chyb okolo tím, že nebude moc sáhnout po těch souborech).
Navíc pokud se na to zaměříš a budeš třeba zkoušet reprodukovat chybu, tak se ty logy nechají přesměrovat do jiného umístění (to může být kdekoliv, klidně na flešce).
Mrkni na příkaz: wevtutil
Např. wevutil sl System /lfn:"E:\System.evtx"
nebo jednotlivý kanál:
wevtutil sl "Microsoft-Windows-Storage-ClassPnP/Operational" /lfn:"E:\Storage-ClassPnP.evtx"
Pak restartuješ službu EventLog nebo celý systém.
Dělal jsem to třeba na nějakém video serveru, který měl chytře mrňavý eMMC disk na systém i aplikace a pak velké pole na data, kam jsem pak musel nastavit i ty logy.
Nakonec to jde posílat i na jiný Windows počítač po síti..
To se zas nastavuje přes wecutil na straně, co přijímá. Dělal jsem to jednou a jel jsem jen podle kompletního návodu, už si to nepamatuju přesně.
Ale tady podle předchozího postu, kdy psal o náhodném mizení souborů ve složce a následném restartu, mi úplně nevyplývalo, že by to en-bloc nemohlo od toho momentu vůbec zapisovat na disk.
31. 8. 2025, 15:37 editováno autorem komentáře
Remote kernel debugger je samozřejmě taky další možnost, akorát v tomhle případě bych řekl, že by to byl trochu kanón na vrabce.. a pokud třeba neladíš nějaký specifický ovladač (tady bude nejspíš standardní stornvme.sys) nebo hodně záludnou chybu, kdy například chceš opravu jít až k jednotlivým requestům (IRP), tak to ukládání standardních eventů, včetně těch nekritckých (operational) na druhý disk nebo forwarding na jiný počítač, může být užitečnější.
Případně pokud je potřeba dohledat, jestli chyby nastávají jen při nějakých specifických situacích nebo workloadech, tak je k tomu užitečný i třeba Windows Performance Toolkit (wpr, wpa) a tracing do .etl souborů, abys třeba odhalil, co se děje okolo (procesy, DPC fronta, sleepy, detaily o IO requestech). Sondy pro tracing samozřejmě něco sežerou samy o sobě, ale zas it to poskytne možnost zobrazit v čase jako timeline, dát dohromady s eventy atp.
Dobře napsáno. Jen bych doplnil, že NVMe SSD by měly ve SMART logu by měly být i události překročení warning a critical temperature, s informací o teplotě na jednotlivých senzorech. Pokud SMART čtete pomocí nějaké utility, tak je potřeba ji spustit v admin módu, jinak nejspíš nepřečte vůbec nic.
Další možností je slíznout čas od času informaci o teplotě SSD a uložit do logu, třeba přes Get-StorageReliabilityCounter, counters Temperature a TemperatureMax. Pokud je v logu vidět postupný nárůst teploty SSD, a pak už nic :), tak asi máte příčinu.
Tak to je dobrý. Už asi měsíc mám doma komponenty pro nové PC a zatím nebyl čas to sestavit. Mezi nimi pochopitelně SSD Crucial P3 plus, který je též na blacklistu (s Crucialem jsem byl vždy spokojený).
Zatím počkám, jak se situace vyvine, ale je celkem pravděpodobné, že pro sicher koupím jiný SSD, protože jak naschvál se něco podělá v ten nejblbější moment.