Ne, chtěl jsem napsat přesně to, co jsem napsal. Zápis je v drtivé většině případů zároveň i přepis, zejména v případě SMR, kde se musí přepsat i kvůli jednomu bloku několik sousedních stop. Jediná výjimka je úplně čistý disk, ale to je případ, který se u takového disku vyskytne pouze jednou. A protože defragmentace trvá u takových disků nesmyslně dlouho (kapacita vs. pomalost zápisu,) tak se k "čistému disku" už nikdy nepropracuješ.
Proto taky SMR doporučuju jen jako archivační disk, na kterém se prakticky nic nemaže, jen se přidávají data a zápis není přepis (jak to píšeš). Technicky máš samozřejmě pravdu, ale každý nearchivační disk, kde se běžně pracuje (mění, maže), velmi brzy dospěje do stavu "přepis only." Velká cache a často i "CMR cache" část disku dokáže na chvíli tento problém odsunout - dokud se nenaplní daty a požadavky, ale nakonec stejně firmware disku kapituluje a sníží rychlost zápisu.
SMR disky podporují TRIM.
Po smazání souboru a provedení TRIM se zóny (většinou 256MB) označí za prázdné.
Takže SMR disk lze udržovat v dobré kondici pro zápis.
Pro soubory které jsou násobně větší než zóny to může fungovat docela dobře. Například filmy, jak píšete.
Opakuji že 20% kapacity je mizerný bonus za tyto komplikace.
25. 11. 2025, 05:38 editováno autorem komentáře
Předevčírem jsem na 6TB externím SMR (ale od Seagate), který byl úplně zaplněný (zbývalo asi 2 GB) smazal 950 GB, hned zase nahrál 900 GB, a proběhlo to bez nějakých viditelných problémů.
Pamatuju starší 2,5" externí disk, který měl velké problémy s pádem rychlosti na minimální úroveň a předpokládám, že to mohlo být SMR, ale tedy to neregistruju (Seagate BackupPlus Hub 6 TB).
Trim na průběžně neotrimovaném, nijak zvlášť využivaném 256GB SSD s linuxem, kde trim probíhá jednou týdně, trvá několik dlouhých sekund. U podobně používaného SMR disku o kapacitě >10TB si troufám tvrdit, že takový scénář bude trvat několik minut. Trim prováděný onlinově bude mít závažné dopady na výkon. Kopírování velkých souborů ad-hoc není běžné využití systémového disku.
Motáte zóny na SMR s clustery na SSD.
256MB má zóna na SMR
4KB má klastr na SSD
To je dost zásadní rozdíl.
Takže z Vašeho odhadu "několik minut" jsou milisekundy. Takže dopad na výkon bude nula.
SMR není vhodný pro systémový disk!
(Dnes už žádné HDD, ani můj 10 000 RPM VelociRaptor co mám v šuplíku, ale Win7 na něm běhali jak z praku, člověk nepoznal rozdíl mezi SSD, až na ten rachot hlaviček :-)
OK. Je tam zmatek v názvosloví.
AI přeložila cluster jako klastr ale má tam být blok.
Což může být matoucí.
Pro někoho kdo neumí anglicky.
Ale na podstatě to nic nemění.
Zkusím to česky.
SSD má buňky, ty jsou uspořádané v mřížce.
Mřížka se dělí na stránky o velikosti 4KB, které jsou seskupené do bloků o velikosti většinou 512KB
TRIM spuštěný nad SSD pracuje s bloky.
Takže řádově KB podle kapacity disku a modelu.
SMR má úplně jinou strukturu takže TRIM spuštěný nad SMR diskem nepracuje s bloky ale se zónami, které jsou řádově větší. 256MB.
Takže operace TRIM nad SMR bude 1000× rychlejší než operace TRIM nad SSD.
Kapacity jsou jen 10× větší.
I když vezmu v úvahu že SSD má 10× rychlejší sekvenční zápis než SMR. Tak SMR bude TRIMovat rychleji.
Vaše domněnka, že doba TRIMu bude přímo úměrná kapacitě, je úplně mimo.
Jestli nevěříte udělejte si test.
Pan Olšan jeden udělal.
Takže máte návod jak vyvrátit Vaše tvrzení o pomalém zápisu na SMR.
Ovšem přepis je velký problém.
Tam nepomůžu TRIM ani defragmentace.
27. 11. 2025, 23:07 editováno autorem komentáře