Odpověď na názor

Pokud vycházíte z popisu reklamštinou, která má zakrýt problémy výrobce a nabalamutit uživatele, že je to tak lepší... úplně to samé v bledě modrém je SMR. Samozřejmě ty popisy jak to funguje jsou určeny pro laickou veřejnost a podle toho to vypadá. Nestačí jen číst, ale srovnávat se zkušenostmi z praxe.
Je složený z původních 512Bn. jenže odpadá u tohoto řešení to 8x smetí okolo každého sektoru, takže správně vidíte, že opravdu zabírá fyzicky méně bitů=zabere na plotně méně místa. Takže dojde fyzicky k navýšení kapacity o nějakých 10% na plotnu. A při správné velikosti souborů i rychlosti čtení, když se na stopu vejde více dat.
Cluster to je. Akorát opravný kód se nemusí dát extra ke každému sektoru 512n, ale dá se nakonec clusteru sektorů.
Takže ano, fyzicky to zvedne nepatrně kapacitu, výrobci to usnadní život a uživateli to komplikuje život.
Ale opět musím odkázat na test řad WD, kde toto všechno v těch grafech je jasně vidět. Zejména zápis a zápisové IOPS 512Bn vs 512Be. Jak známo, každá emulace ztojí nějaký výkon.
Z této řady mám WD Blue 1TB za výprodejovou cenu (no nekup to) a přeznačený WD Gold na HGST 7k2.
U toho Blue EZEX jsem poněkud na rozpacích z toho, co vidím v grafu sekvenčního čtení a co předvádí WD Black LPLX jako další zástupce Advanced Formatu v testu.
Při mém pracovním nasazení jsem dělal časové testy Gold/Blue v sekundách:
zavedení systému G 35/B 33
Libreoffice načtení obrazovky se seznamem dokumentů/otevření dokumentu G 4/3 B 4/3.
Virtualbox W7 do načtení plochy G 22/ B 22.
Chromium G 10/ B 17!!!.
Pocud to odpovídá výhodám/nevýhodám 512Bn a 512e.
A pak nečekaný nářez u defragmentace souboru W7.vdi o velikosti 12,6 GB pod ext4. Když Blue nebyl hotový ani po 2 hodinách, tak jsem defragmentaci přerušil a změřil, jak dlouho to řeší Gold jako zástupce 512Bn a ntb WD Black LPLX jako zástupce 512Be. Gold 1% udělal za 3,7s a ntb Black 1% za 8 s.
Blackem z úplně stejné kategorie jsem ověřil, že 512e to je schopné dát v rozumném čase i s hendikepem AF při zápisu. Proto jsem W7.vdi nakopíroval ještě na jiné oddíly, abych vyloučil další skrčku výrobce a to přemapování velkého poškození plotny do jiné oblasti už z výroby. Čemuž by napovídalo to, co jsem viděl v grafu sekvenčního čtení. Výsledek stejný.
Takže, pokud vyloučím chybu ve FW, tak je to exemplární ukázka nevýhody 512Be při zápisu. Nakonec v dříve odkázaném grafu všechny disky s 512Be ztrácí na 512n. Navíc toto chování odpovídá clusteru sektorů 512n.
Když jsme u toho. Jako novinář obešlete, nikoliv tiskový odbor, ale technické ředitele výrobců disků a položte jim otázku, zda sektor 4kB je na plotně složený z 8 x 512B fyzických sektorů, nebo celý sektor 4kB je fyzicky opravdu na plotně v celku. A k tomu položte kontrolní otázku, jak vyřešili synchronizaci čtení/zápisu tak dlouhé řady dat v kuse a jestli i mezi daty jsou uložené synchronizační značky.
Nepředpokládám, že na férovku odpoví, že tahají zákazníky za fusaklu a ještě prozradí své ojebávací nou-haf.