Autor: Jurek (laskaje_at_ctrvax.vanderbilt.edu)
Data: Fri 14 Jun 1996 - 05:52:03 MET DST
lis_at_okapi.ict.pwr.wroc.pl (Jarek Lis) wrote:
>Jurek (laskaje_at_ctrvax.vanderbilt.edu) wrote:
>: Moze mi sie pogorszylo, ale nie widze dlaczego zapelnianie partycji
>: "od srodka" pozwala na oszczednosc na ruchu glowic. Po mojemu, zapis
>: na zewnetrznych cylindrach (o wiekszej ilosci sektorow) ma same
>: zalety. Nie tylko operacje odczytu/zapisu sa szybsze ale i (przy danym
>: stopniu wykorzystania dysku) ilosc zapelnionych cylindrow jest
>: mniejssza a wiec sredni skok glowic krotszy.
>: Na czym polega ten zysk na "srodkowaniu"?
>Jest, jesli sie zalozy, ze na poczatku partycji sa dane po ktore
>czesto sie siega. FAT w dosie, inody w unixach, swap, command.com
>czy NC. Wtedy glowica zwykle jest na srodku, i w obie strony
>ma tylko pol drogi.
To FAT sie nie zmiesci w cache? Command.com jest tak czesto czytany?
Watpie, a jezeli - do cache go! NC - to juz interakcja z uzytkownikiem
i dodatkowe 10ms jest niezauwazalne. Swap - OK, ten dobrze byloby miec
pod reka, ale czy jest on na poczatku dysku (w sensie instalowany jako
jeden z pierwszych zbiorow)? A jak komus przyjdzie ochota zmienic
rozmiar? A co z porzadkowaniem dysku?
Reasumujac zysk powinien polegac na trzymaniu zbiorow do ktorych sie
czesto siega w srodku wykorzystanego obszaru. OK, zgoda, tyle tylko,
ze opisane zapelnianie dysku "od srodka" wcale IMHO tego nie zapewnia.
Korzysci sa wiec watpliwe, a straty pewne.
Zeby naprawde odniesc korzysci z zapelniania od srodka trzeba by
wbudowac w SO logike wykrywajaca zbiory, do ktorych dostep jest
czesty, a ich rozmiar nie pozwala na trzymanie w cache. Takie wlasnie
zbiory musialby potem w ramach porzadkowania stopniowo "przerzucac" na
(logiczny) poczatek (fizyczny srodek) dysku. No ale skoro i tak ma to
robic dynamicznie, to czemu nie zapelniac dysku od (fizycznego)
poczatku i "przemieszczac" takie zbiory do srodka zajetego obszaru?
Ktos ma jakies bardziej przekonywujace argumenty?
Jurek
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Tue 18 May 2004 - 12:45:24 MET DST