Tomasz Chmielewski pisze:
> W przypadku dlugich plikow odbywac musialoby sie to nastepujaco:
> Dysk1: odczyt seek odczyt seek odczyt
> Dysk2: seek odczyt seek odczyt seek
> Skakanie glowica blok dalej nie jest wcale bardziej wydajne niz liniowy
> odczyt po kolei. Ba, moze byc nawet wolniejsze.
Jakie skakanie? Dysk buforuje zawsze całą ścieżkę, na której
znajduje się głowica, więc nie ma mowy o skakaniu o blok.
Owszem, ścieżka nie zawiera zbyt dużo danych, ale skok o
dwie ścieżki nie jest wcale zauważalnie wolniejszy niż skok
o jedną ścieżkę.
> A tak generalnie, to jakikolwiek RAID nie widzi checi dostepu do jednego
> czy drugiego pliku, tylko do pewnych obszarow dysku, co jeszcze bardziej
> komplikuje sprawe.
No i tu jest pole do popisu dla systemu plików i systemu
wejścia/wyjścia w OSie. Jeżeli system plików jest w stanie
wygenerować duże ciągłe odwołania do warstwy dyskowej,
oprogramowanie macierzujące może podzielić czytany blok
na dwa duże obszary czytane sekwencyjnie i wrzucane przez
DMA do jednego bufora.
I praktycznie każdy system dzisiaj buduje jak największe
bloki danych, bo tylko w ten sposób można wykorzystać
funkcję odczytu wielosektorowego kontrolerów dyskowych
oraz sensownie wykorzystać DMA/BM.
W Linuksie na przykład ostatnie zmiany w jądrze mają
na celu umożliwienie tworzenia wielkich (powyżej kilkuset
kilobajtów) pojedynczych odwołań do niskich warstw we/wy,
co zmniejsza narzuty na bloki danych i umożliwia właśnie
przyspieszenie macierzowania i zmniejszenie obciążenia CPU.
Owszem, stronicowanie przyspieszy niewiele lub nic, bo 4 KiB
to za mało, by widać było zysk z podzielenia tego na dwa
odczyty po 2 KiB. Ale w RAID 0 też to nie przyspiesza :)
-- |""""""""""""""""""""""""""""""""""""""""""""""""""""""""""| | Radosław Sokół | http://www.grush.one.pl/ | | | Administrator, Politechnika Śląska | \................... Microsoft MVP ......................../Received on Mon Jan 14 13:45:15 2008
To archiwum zostało wygenerowane przez hypermail 2.1.8 : Mon 14 Jan 2008 - 13:51:13 MET