Advanced Format HDD s 4kiB-sektorovou vnitřní geometrií

Poslední přibližně dva roky se nové pevné disky, ale i SSD disky vyrábějí s vnitřní geometrií 4096bajtových (4 kiB) sektorů s emulací klasických 512bajtových sektorů pro BIOS, operační systém i aplikace z důvodů kompatibility (většina BIOSů ani operačních systémů na 4kB sektory není připravena). Snadno ale nastává problém s výkonem, pokud hranice clusterů (jednotek souborového systému) nedosedají přesně na hranice sektorů na fyzické vrstvě. Téměř zaručeně se to stane u Windows XP a starších a rovněž v případě, že takřka jakýkoli „partition manager“ včetně toho výchozího ve Windows s diskovými oddíly manipuloval.

Wikipedia nabízí výstižný obrázek ukazující na rozdíl mezi 512b a 4096b sektorovou geometrií:

Následující text používá konvenci pojmenování „kiB“ (kibibajt = 1024 bajtů) a „MiB“ (mebibajt = 1024 × 1024 = 1048576 bajtů), označovanou v operačních systémech (s výjimkou OS X 10.6+) nicméně jako kB, MB atd. Velikosti disků jsou naopak „GB“, kde giga je skutečně známou předponou SI, kde 1 GB = 10^9 bajtů. Chaos v tomto značení je samozřejmě příčinou toho, proč 1TB disk se v systému jeví jako ~0.9095 TB (správně TiB)… více na Wikipedii

Standardně při formátování disku podle MBR začíná první primární oddíl na 512bajtovém sektoru č. 63 (první sektor má č. 0). Jedná se tedy o 64. sektor od začátku disku. Standardně mají dnešní souborové systémy (NTFS, EXT3, EXT4) 4kiB velikost clusterů. Při počítání v násobcích 4096 bajtů ale vychází, že prvních 512 bajtů prvního 4096bajtového clusteru souborového systému se nachází na posledních 512 bajtech předcházejícího 4096bajtového sektoru a zbývajících 4096 − 512 = 3584 bajtů se nachází na dalším sektoru. Tento posun se pak samozřejmě opakuje na celém diskovém oddílu, a pokud následující oddíly přímo doléhají na konec předcházejících, předsazení clusterů o 512 b se opakuje. Jelikož pevný disk používající interně 4096bajtové sektory zapisuje a čte vždy celé tyto sektory (neboť potřebuje pracovat s jejich hlavičkami a opravnými ECC korekčními mechanismy, viz diagram výše), znamená to, že pro čtení každého 4096bajtového clusteru souborového systému musí disk číst dva 4096bajtové sektory, půlku dat zahodit a emulovat čtení osmi 512bajtových sektorů (při použití čtecí cache a čtení souvislého bloku dat se většina redundance naštěstí odstraňuje). Při zápisu je to ještě zdlouhavější (mj. i proto, že často je cache pro zápis z bezpečnostních důvodů vypnutá). Výsledek toho všeho je, že takový nový disk, který je tímto způsobem špatně naformátovaný (nezarovnaný), bude vykazovat podstatně horší výkon při čtení a ještě častěji při zápisu. Ještě katastrofálnější výsledky se dostavují při použití horších SSD disků, které prakticky všechny pracují s většími sektory.

Můj problém

Problém u mě byl v tom, že jsem jednak nevěděl, že už můj dosud používaný 400GB disk už s tímhle vnitřním rozložením operuje (ačkoli ani na něm to „Advanced Format“ není uvedeno, a většina nástrojů na rozdělení disku, se kterými jsem dosud pracoval (Windows XP diskmgmt.msc / diskpart i jinak vynikající free nástroje EaseUs Partition Manager nebo MiniTool Partition Wizard) tohle taky neberou v úvahu. Výsledkem tedy bylo, že všechny mé diskové oddíly (systémový NTFS+Truecrypt s Windows XP, datový NTFS+Truecrypt i systémový EXT4 s Debian Linux) měly své krásné 4kiB clustery na překryvu dvou 4kiB sektorů disku. Přidejme k tomu šifrování Truecryptem a trvale skoro plný disk vytvářející velmi rychle neuvěřitelnou fragmentaci a je jasné, že k maximální rychlosti disku kolem 90 MiB/s jsem se zpravidla neblížil ani z třetiny, resp. situace už došla tak daleko, že při čtení mnoha menších, a/nebo silně fragmentovaných souborů, se rychlost pohybovala v řádu jednotek MiB/s a nestačila ani na čtyřrychlostní vypalování DVD bez pozastavování vypalování. (O rychlosti operačního systému nemluvě.) Problém jsem ale přisuzoval jen na fragmentaci a šifrování.

O tom, že už nějaké dva roky se dělají disky s 4kiB vnitřní strukturou sektorů, a že jsem obětí tohoto jevu jsem se dozvěděl, až když mi z německého Amazonu dorazil nový 1TB 2,5“ disk, kde je na štítku jakési logo Advanced Format, které jsem neznal, a až následně se (thx to Wikipedia) ukázalo, o co teda jde.

Mé řešení

Po dvou dnech jsem zvládl nový disk naformátovat správně (za pomocí linuxového GNU parted s parametrem „-a optimal“ zarovnávající všechny oddíly na bezpečné hranice 1 MiB) a po vyzálohování všeho na tom dosavadním disku na ten nový i nedestruktivní zarovnání (realign) těch stávajících 400 GB v asi 8 oddílech na hranice těch 4kiB sektorů, za pomoci Samsungem doporučeného a poskytovaného nástroje od Acronisu (Alignment tool). (Dočasně jsem systémový oddíl s Windows před použitím v Truecryptu dešifroval (jinak lidi reportují poškození oddílu a nemožnost jej znovu připojit!) a až po skončení všeho jej nechal zašifrovat znovu.

Kupodivu, ten nový 1TB disk mi příslušný nástroj nechtěl přechroupat, protože jej ještě ani neznal (Acronis dodává svůj nástroj jednotlivým výrobcům disků zablokovaný pro všechny krom vybraných modelů daného výrobce; a zřejmě model vyrobený v březnu 2012 ještě do databáze nepřidal – ještě že jsem na něm ještě neměl data a mohl využít svobodný GNU Parted). Pro zajímavost, jak jsem s GNU parted postupoval:

# parted -a optimal /dev/sdb
> u MiB 
> p
> mkpart primary 1 200
> mkpart primary 200 25200
> mkpart logical 25201 100%

Příkaz „u MiB“ přepíná používané jednotky na MiB, příkaz „p“ vypíše parametry disku, zejména celkovou kapacitu, se kterou lze operovat při určování velikostí jednotlivých diskových oddílů. Logické oddíly jsem zapisoval s počáteční adresou posunutou o přibližně 1 MiB oproti konci předcházejícího, neboť rozšířený oddíl, ve kterém jsou logické oddíly zahrnuty, obsahuje nové hlavičky, které všechny logické oddíly posouvají. Při pokusu psát přesně pokračování minulé adresy mě parted varoval, že oddíl nebude odpovídat požadovanému „optimal“ zarovnání na 1 MiB a nejjednodušším řešením bylo právě tento posun. Kontrolu správného zarovnání pro právě vytvořené oddíly i oddíly vytvořené dříve na jiných discích lze provést příkazy align-check optimal #, dosazující za # číslo kontrolovaného oddílu. Odpověď je buď aligned nebo non-aligned a nové oddíly by měly být vždy „aligned“  :-) Jak vynutit „optimal“ zarovnání při použití grafické nadstavby gparted, jsem nepřišel, proto jsem to radši vše udělal ručně.

Shrnutí:

  • běžný uživatel s Win Vista/7/8, co si nechá celý disk naformátovat instalátorem Windows (a dál se v tom nevrtá v diskmgmt.msc nebo jiném partition manageru), by neměl mít problém.
  • Uživatel Windows XP (já) má vždy problém, pokud si neprovede ve speciálním softu od Acronisu zarovnání nebo si nevytvoří předem prázdné oddíly v GNU parted, a pak se zcela vyvaruje jakékoli manipulace s nimi prostřednictvím diskmgmt.msc / diskpart a jakéhokoli jiného partition manageru.
  • Uživatel GNU/Linuxu a jiných UNIXů nemá problém, pokud si oddíly vytvoří v GNU parted s parametrem „-a optimal“ (zarovnávající na 1MiB hranici) případně asi i „-a minimal“ (zarovnávající právě na 4kiB hranici), ideálně si ještě přehodí používané jednotky na MiB (po spuštění parted zadat „u MiB“).
  • K tomu všemu je ještě nutné si souborový systém udržet s velikostí clusterů 4kB (případně asi i celé násobky).

Naštěstí pro NTFSEXT3/4 je 4kiB cluster standardem.
Jestli standardní instalátory jednotlivých Linux distribucí používají vnitřně GNU partedminimal/optimal alignací oddílů, nevím.

Problém 3.0

Problémy dále mohou nastat u RAID polí, při virtualizaci ve VirtualBoxu a použití šifrovaných kontejnerů (Truecrypt), kde to ale bylo i dřív, neboť mezi sektory a virtuálním diskem (skoro) vždy leží ještě mezivrstva hostitelského souborového systému, co zpravidla má taky 4kiB velké clustery (pozoruhodné hacky VirtualBox obrazů se objevují třeba tady) a je spíš náhoda, pokud hranice clusterů guesta odpovídají hranicím clusterů hostitele, které zase odpovídají hranicím sektorů hostitele ;-)

SWF animace: Partition (mis)alignment effects

Jestli je problém i s Truecryptem šifrovanými celými oddíly, mi není úplně jasné, právě to testuji v praxi. Vytvořil jsem správně zarovnané oddíly v GNU parted a naformátovat je pak nechal v Truecryptu – předpokládám, že by k žádnému posunu dojít nemělo. Parted i Acronis Alignment tool tvrdí samozřejmě, že partition je zvenku zarovnaná správně :-)

Rozšíření diskové kapacity na více než trojnásobek kapacity původní (400 GB + 1 TB) se mi zároveň konečně uvolnilo místo na přeplněných oddílech starého disku, čímž jsem si mohl dovolit provést úplnou defragmentaci a tak si minimálně do doby, než se zaplní i ten nový disk, užívat relativně dobře fungujícího systému. (Interní 2,5“ 1GB disky se teď — minimálně na německém Amazonu, který mi to do Belgie poslal bez dalších poplatků dva dny po objednání — prodávají pod 100 euro za kus, což je prima pro rozšíření notebooku o druhý interní disk, výměnou za hotswap DVD SATA mechaniku). Lze samozřejmě využít i eSATA nebo USB 3.0 rozhraní (kdo jej má). USB 2.0 se svými max. nějakými 25 MB/s netto v reálu není úplně terno řešení při terabajtových kapacitách.

O autorovi

Jmenuji se Martin Malec a pracuji v současné době na řadě projektů. Ten hlavní se týká hledání a nacházení nirvány potažmo osvícení pod vedením Namkhai Norbu Rinpočheho a dalších mistrů, z těch ostatních to pak je hledání modelů pro udržitelnou společnost a experimentování v duchu permakulturního přístupu k zahrádkářství; a aktivní členství v různých organizacích a skupinách, jakými jsou Komunita dzogčhenu, Hnutí Brontosaurus či Archetypal, o.s. či RozLETe.cz. Pracuji ve firmě vyrábějící ekologickou drogerii.
Příspěvek je zařazen do tématu IT s tagy , , , , , , , , . Trvalý odkaz.

3 komentáře u Advanced Format HDD s 4kiB-sektorovou vnitřní geometrií

  1. Martin napsal:

    Zkouška rozhlasu, zkouška rozhlasu. Vypadá to, že Facebook integrace rozbila antispam plugin pro přidávání komentářů přímo.

Napsat komentář

Vaše emailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *

Můžete používat následující HTML značky a atributy: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>