Autor: MaraBut (martys_at_f2virt.onet.pl)
Data: Mon 19 Nov 2001 - 10:59:24 MET
Piotr Pastuszka napisał :
>MaraBut napisał:
> > [...] Idea stripingu polega wlasnie
> > na tym by zastapic transfer jednego duzego pliku z jednego nosnika,
> > jednoczesnym transferem wielu malych plikow [...]
> NIeprawda. Moze byc roznie. Ale generalnie ide stripingu to jest tak jak
> mowisz ale tak naprawde to chodzi o to by jak najbardziej losowo rozlozyc
> dostep do dyskow.
Ale przeciez na to nie masz wplywu. Jesli zapisujesz plik na pojedynczym HDD
to kolejne porcje danych umieszczane są w kolejnych wolnych blokach na
dysku, tak jak wskazuje tablica FAT. W przypadku sprzetowego stripingu
wyglada to tak, ze kontroler zlicza przesylane dane i gdy licznik wskaze
koniec bloku po prostu nastepne dane kieruje na kolejny dysk w macierzy.
Wybor tego dysku moze odbywac sie oczywiscie losowo, ale to wymagaloby
dodatkowej informacji w FAT, tak by kontroler wiedzial skad brac kolejne
bloki przy odczycie. Zaawansowane kontrolery SCSI RAID Adapteka czy DPT, z
wlasnym cache na karcie moze stosuja jakies wyrafinowane sztuczki dla
poprawy efektywnosci, ale HPT370 to raczej proste urzadzenie i dyski wybiera
w sposob KOLEJNY a nie losowy. Na tym polega "równomierne obciążenie"
("balanced load") dla dwóch dysków. Metoda losowa moze zdawac egzamin przy
duzej (kilkanascie ?) liczbie dysków w macierzy, ale nie sadze aby dawala
istotne korzysci (w przypadku dyskow IDE przynajmniej).
> > [...] Rozmiar bloku zwiazany jest natomiast z rozmiarem bufora HDD.
Powinien byc taki,
> >by dysk zdazyl zapisywac / odczytywac kolejne bloki z nosnika zanim bufor
sie
> > napelni, co spowoduje skokowy spadek szybkosci transferu danych. [...]
> ? tego nie rozumiem
To sprobujemy wyjasnic na przykladzie :o)
1. Kontroler nie ma wlasnego bufora danych - tylko 256B FIFO na kanal IDE
2. Z szyny PCI naplywaja dane ktore trzeba zapisac na dysk (macierz).
Maksymalny transfer (teoretycznie) to :
33MHz przy 32bitowej szynie danych daje 133MB/s w trybie burst i ok 66MB/s
w trybie busmaster.
3. Kontroler kieruje dane na magistrale IDE tego dysku, na ktory wskazuje
licznik blokow.Nazwijmy go dyskiem (1). Dane przesylane sa z predkoscia
100MB/s (ATA100)
4. Po przeslaniu bloku, kolejne dane kierowane sa na nastepny dysk w
macierzy( powiedzmy (2) ). W tym czasie dysk (1) zapisuje dane na nosniku.
Predkosc zapisu jest znacznie mniejsza niz transmisji i np. dla Maxtora
D540x wynosi od 18 do 38 MB/s, totez jesli nadejdzie kolejna porcja danych
(a nadejdzie bo pliki zazwyczaj zajmuja wiele blokow) to jest umieszczana w
cache i czeka w kolejce do zapisu. Analogiczna sytuacja powstaje na dysku
(2). Po pewnym czasie bufory w HDD sa pelne i sa w stanie przyjmowac dane
tylko z taka predkoscia, z jaka bufory sa oprozniane (tzw. internal transfer
rate).
Jak na razie wszystko wydaje sie oczywiste, prawda ? :o)))
Zastanowmy sie jak to sie wiaze z rozmiarem bloku. Im jest on mniejszy, tym
czesciej "zmieniane" sa dyski do ktorych kontroler przesyla dane. Jednak gdy
bufor sie napelni to dane mozemy dopisywac tylko w tempie w jakim powstaje
wolne miejsce w buforze. Oznacza to ze mniejsze bloki mozna czesciej
"upychac" na koncu bufora, co wplywa nie tylko na szybkosc transmisji, ale i
na zajetosc szyny PCI (mniejsze przestoje w transmisji).
Przy odczycie rozmiar bloku ma znaczenie o tyle, ze przez szyne latwiej
przeslac bez przestojow niewielkie paczki danych niz duze bloki.
> [...]A tutaj imho kwestia wydajnosci wynika z faktu ze to dyski IDE i ze
> kontroler nie ma wlasnego cache. [...]
To prawda. Niestety :o(
> > [...]czas dostepu dla macierzy moze byc nawet gorszy niz dla
pojedynczego
> dysku -
> > w skrajnym przypadku oczywiscie.
>
> to tez nie do konca prawda, bo co to jest u ciebie macierz ?
> za tym kryje sie zazwyczaj jakis kontroler.
> W przypadku SCSII dzialajacy asynchronicznie.
> tj wysylal 20 roznych zadan a potem np odbiera odpowiedzi.
> W przypadku KOntrolera IDE jest tak ze wysyla 1 zadanie i czeka na
> odpowiedz. Potem wysyla drugie i czeka na odpowiedz itd.
Ale tutaj mowimy wlasnie o IDE.
Poniewaz pliki "sklejane" sa z kolejnych bloczkow znajdujacych sie na
roznych dyskach, to w skrajnie niekorzystnym przypadku, trzeba czekac na
pozycjonowanie WSZYSTKICH dyskow bioracych udzial w transmisji, wlasnie z
powodu kolejkowania zadan w kontrolerze. W rzeczywistosci kontroler
obsluguje dyski "prawie" rownolegle, tzn. wysyla polecenia rownoczesnie do
wszystkich dyskow, lecz przed nastepna operacja musi czekac na odpowiedz
wszystkich dyskow ( jest to zwiazane z mechanizmem dostepu do danych -
licznik blokow), wiec moze sie teoretycznie zdarzyc i najgorsze ;o)
> > Nadmierne zmniejszenie rozmiaru bloku oznacza, ze dyski sa czesciej
> > pozycjonowane, co pogarsza ogolna wydajnosc, chociaz nie tak znacznie,
bo
> > wspoczesne dyski maja duzy cache (rzedu 2MB) i stosuja algorytm "read
> ahead" [...]
> Ten cache takze sluzy do zapisu. a wiec nie tylko 'read ahead.'
A gdzie napisalem ze sluzy tylko do odczytu ? :o)
Pod Windowsami widoczny przyrost wydajnosci daje zwiekszenie transferu z
dysku. Nie pamietam w tej chwili proporcji, ale ilosc odczytow z HDD
znacznie przewyzsza ilosc zapisow - dla przecietnego uzytkownika w kazdym
razie.
To juz taki system : ladujesz aplikacje o rozmiarze 100MB zeby w efekcie
zapisac efekty wlasnej pracy w objetosci 300kB.
:o)))))
> Twoje rozumowanie ma czesciowo sens jezeli zalozy sie komus zalezy jedynie
> na szybkim transferze.
> Ale zazwyczaj ludziom chodzi o duzo roznych dostepow rownolegle. ( na
> serwerach obslugujacych np 50+ uzytkownikow)
A zauwazyles o czym mowa w topicu ?
;o)
To chyba nie ten przypadek ...
Mowimy o korzysciach dla uzytkownika plyty MS-6380 V2.0 z kontrolerem bodaj
Promise (nie pamietam co ma na pokladzie) i dwoma dyskami IDE.
:o)))))
Pozdr.
MaraBut
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Tue 18 May 2004 - 23:22:01 MET DST