Autor: Pastuszka Piotr (piotrpa_at_kpwig.gov.pl)
Data: Tue 20 Nov 2001 - 14:37:40 MET
Użytkownik "MaraBut" <martys@_nospam_priv.onet.pl> napisał w wiadomości
news:9tal3v$q6t$1_at_news.onet.pl...
> 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.
Oczywiscie
> 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
Ale mnie nie chodzilo ze zapis losowy, ale ze potem odczyt losowy.
W sensie jak 10 aplikacji wola o maly dostep do macierzy o 10 dyskach to
statystycznie jedna odwola do jednego dysku.
i kazda do innego co oznacza ze tylko jedna aplikacja obciaza 1 dysk a nie
10 aplikacji.
To uproszczenie ale taki jest sens.
High serwery maja i po 500 dyskow tylko wlasnie z tego powodu.
> 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).
j.w . mam nadzieje ze opis rozjasnil moje spojrzenie.
> 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)))
Oczywiscie :)
> 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.
Oczwiscie i Twoj opis zaklada ze kontroler nie ma cache i dotyczy
przecietnego zjadacza ktory stosuje conajwyzej 2 dyski w Raid 0 lub 1.
W przypadku serwerow stosuje sie kontrolery z wlasnym cache i wlasnie wiecej
dyskow co powoduje ze nie ma tego efektu zapchania wszystkich cache na
kazdym z dyskow.
A wiec duzy blok jest OK,
Dodatkowo przy odczycie jest to co pisalem wczesniej i stad zalecam Duze
bloki.
> 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)
I wlasnie dlatego lepiej duze bloki bo wieksze prawdopodobienstwo ze caly
ten fragment ktory chcesz czytac zmiesci sie na jednym dysku, i nie trzeba
angazowac jak to napisales wszystkich.
> 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)))))
OK , w tym przypadku Mozesz miec 100% racji, ale dopuki nie sprawdzilbym w
zaleznosci od aplikacji to nie bede sugerowal Twojej opcji.
Powiedz mi jeszcze jakiego rzedu sa roznice miedzy proponowanym przez CIebie
16KB stripem a maxymalnym dostepnym na tamtym kontrolerze ?
( w %)
PiotrP
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Tue 18 May 2004 - 23:22:36 MET DST