Ofset jednotlivych partition

[Dan Lukes]

Jindra Fucik napsal/wrote, On 01/25/06 09:13:
>> Disky pouzivaji konstantni uhlovou rychlost. Stare disky pritom
>> pouzivaly konstantni pocet sektoru na stope.
> 
> ... a hodne stare disky pouzivaji prekompenzaci a ruzne prokladani sektoru, 
> aby se zotavily pri vybavovani jednoho sektoru, ale to je asi jen rejpava 
> poznamka, posledni disk kterej ma takove vlastnosti ma stejnou hmotnost v 
> kilogramech jako velikost v kilobajtech.

	No, asi je na case tema pomalu opustit, ale pro pripad, ze by to nekoho 
(se zajmem o historii) zaujalo bych radeji dodal, ze  prekompenzace 
nesouvisi s rychlosti ale spolehlivosti zaznamu dat a pouziva se dosud 
(jen uz si ji kazdy disk ridi sam a neni ji mozne ovlivnovat "z venku"). 
Prokladani s rychlosti sekvencniho cteni vetsiho mnozstvi sektoru 
skutecne souvisi. Zda se na fyzicke urovni pouziva dosud ovsem nikdo 
krome vyrobce nevi a pouzivat ji na urovni "vnejsi geometrie" nema smysl.

	Ve sve dobe byla optimalizace rozlozeni dat na disku opravdu tezka 
veda. Dodnes muzete FreeBSD tyto parametry nastavit (option -A u 
bsdlabel) - a je jich daleko vic nez o kterych zde uz byla rec - a ono 
skutecne podle zadanych udaju prizpusobovalo metodu pristupu k datum a 
jejich rozlozeni tak, aby dosahlo co nejlepsich vysledku.

	Pamatuju si taky, ze soucasti prednasky o databazovych systemech byla 
cela rozsahla teorie o tom, jak maji byt data v databazi, s ohledem na 
fyzicke vlastnosti disku, po disku rozlozena. Pri navrhu databaze se pak 
skutecne zohlednovaly i konkretni vlastnosti konkretniho disku.

	Ta puvodni otazka byla rozumna - skutecne lze vhodnou organizaci dat na 
disku vyznamne ovlivnit vykon systemu (a nemusi zdaleka jit jen o swap). 
A vic pameti ani vetsi cache to nedokazi vzdy dokonale nahradit 
(napriklad prave u rozsahlych databazi).

	Bohuzel, vyvoj hardware sel takovym smerem, ze momentalne proste 
typicky nejsou k dispozici udaje, ktere by optimalizaci umoznily.

>> 	Zacneme s partition a slice. Jejich fyzicke poradi na disku neni vazano 
>> na poradi v prislusne tabulce. DOkonce lze zaznamy v tabulkach vicve 
>> mene libovolne prehazovat, aniz by to melo na data jiny dopad nez ten, 
>> ze je treba prepsat fstab (urcite specialni postaveni ma nakonec jen 
>> partition 'a' a to jen v pripade, ze je "bootovaci". V takovem pripade 
>> ji tak uplne beztrestne prejmenovavat nelze.

Kaminar napsal/wrote, On 01/25/06 10:52:
> Jestli jsem to spravne pochopil, tak to ani ten offset v bsdlabel nema na
> poradi FreeBSD partitionu zadny vliv?
> 	 #	  size	 offset    fstype   [fsize bsize bps/cpg]
> 	   a:	 81920	      0    4.2BSD     1024  8192    16
> 	   b:	160000	  81920      swap
> 	   c:  1173930	      0    unused	 0     0

	Naopak. Prave ten offset ukazuje na skutecne poradi na disku. V 
naznacene tabulce je swap az za partition [a] a poradi v tabulce pak je 
nahodou shodne s poradim partition na disku.

	Tabulka by ovsem mohla vypadat i takto:

------------------
  	 #	  size	 offset    fstype   [fsize bsize bps/cpg]
  	   a:	 81920	 160000    4.2BSD     1024  8192    16
  	   b:	160000	      0      swap
  	   c:  1173930	      0    unused	 0     0
-------------------

	A tato tabulka popisuje stejnou slice, se stejne velkymi partition jako 
v prvnim pripade, jen jejich proadi na disku je opacne a tedy tentokrat 
ruzne od poradi zaznamu v teto tabulce.

	Jeste jednou ale pripominam, ze termin "poradi partition" se vztahuje 
na "vnejsi zdani poradi". Jak jsou ony dve partition skutecne rozmisteny 
a serazeny na fyzickem mediu nelze obecne zjistit.

						Dan



-- 
Dan Lukes                                   SISAL MFF UK
AKA: dan at obluda.cz, dan at freebsd.cz,dan at kolej.mff.cuni.cz