[LUGOS] promise raid sx6000

[Metod Kozelj]

Howdy!

Egon Pavlica wrote:

>>Druga tezava je 'write performance' tvojih diskov. Sem pozabil, ali jih 
>>imas v kaksnem raidu ali ne. So pa moje izkusnje z raznimi 'resnimi' 
>>    
>>
>trenutno so v software raidu0, ker je malenkost hitrejsi kot raid0 na 
>kontorlerju
>

Sedajle sem se spomnil, kako je s pisanjem (se posebej, ker imas raid0). 
Ce imas po dva (zrcaljena) diska na istem ATA vodilu (torej je en master 
in drugi slave), potem pri pisanju preko tega vodila tocis dvojno 
kolicino podatkov. Sicer je res, da je naceloma ATA vodilo dosti 
hitrejse kot pa disk (recimo 100MBps proti 30MBps), se pa pri vzporednem 
dostopu do vodila maksimalna prakticno dosegljiva kapaciteta kljub vsemu 
zmanjsa.

Aja, pa glede opcije 'unmaskIRQ' za hdparm: ugotoviti, ali ti ta 
nastavitev dela tezave ni prav tezko: ce se med tisto 'zamrznitvijo' 
kurzor miske po zaslonu pomika zelo zatikajoce (meni je vcasih kurzor 
skakal cisto nakljucno, pa vcasih je 'pritisnil' kaksno miskino tipko), 
potem je to tezava, sicer pa ne. Hitrost pisanja pa v bistvu ni s tem 
prav nic povezana.

>vendar branje ni problem, problem je ker si vzame cas za pisanje, potem mi 
>pa medtem ne more brati z diska in predvajanje videa zasteka.... 
>

[snip]

>moja masina je v bistvu samba server za par windows masin, ki obdelujejo 
>video in koncni izdelek pretocijo na raid disk. Tudi pri nalaganju 
>predvajanje zasteka, kljub temu, da je mreza samo 100Mbitna.
>  
>

Tega ne bos resil z nobeno nastavitvijo parametrov diska. Tukaj je 
resitev bodisi patchanje kernela s kaksnim drugim I/O schedullerjem ali 
pa uporaba update s kratkim casom med osvezevanjem.

>mogoce mi bo uspelo z update in hdparm. Mozno je sicer da tega nebi 
>dozivel z  generic i2o driverjem, vendar moram potem vzeti kako drugo 
>jedro, ker v i2o mi nekaj javlja, da ne more resetirati in neke timeoute.
>  
>

Kot receno ... problem je v schedullingu I/O operacij. Ce se pisanje in 
branje postavita v isto vrsto, potem pa v to vrsto postavis pisanje 400M 
podatkov, in potem branje, potem ne bo z diska prebran niti byte, dokler 
tistih 400M ne bo zapisano. S skrajsanjem casa med flushi se bo vrsta za 
pisanje skrajsala na 100M, torej bo branje tistega byta prislo na vrsto 
4x hitreje.
Drugo pa je, ce imas locene vrste za branje in pisanje in ima branje 
veliko prioriteto. Sicer bos imel potem pri pisanju malo manjso 
odzivnost, ampak bo branje imelo manj zamude.

Aja, se eno pri parametrih hdparma: ce imas multcount prevelik, bo za 
vsako operacijo porabljeno nekaj vec casa (bo pa opravljeno tudi vec 
dela). Zato lahko tudi pri schedullerju z dvema locenima vrstama 
odzivnost branja malo pade. Pri taki rabi se (kot ze receno) zelo 
izkazejo SCSI diski. Ti sprejmejo vec ukazov (tipicno 16-64) za branje 
in/ali pisanje in jih izvajajo kakor jim najbolje ustreza (kakor se 
glava pomika). Torej lahko branje prehiti pisanje ze kar v samem disku.
Kot sem ze napisal, ni da bi clovek pri tem pretiraval.

Na moji desktop masini je

/dev/hda:
 multcount    = 16 (on)
 I/O support  =  0 (default 16-bit)
 unmaskirq    =  0 (off)
 using_dma    =  1 (on)
 keepsettings =  0 (off)
 nowerr       =  0 (off)
 readonly     =  0 (off)
 readahead    =  8 (on)
 geometry     = 2586/240/63, sectors = 39102336, start = 0
 busstate     =  1 (on)

in ima prav tako 512M RAMa. Ce dam kaj velikega pisati (recimo "dd 
if=/dev/zero of=zerofile bs=1024k count=1024"), mi ostali procesi resda 
malo pocasneje reagirajo pri dostopu do diska. Ko pa procesi enkrat 
tecejo, je delovanje normalno (racunsko obdelovanje majhnega seta 
podatkov, ...., premikanje misi v X-ih). Pa imam unmaskirq na off. Je pa 
tale ista masina trpela za zatikanjem misi in podobno kadar sem kaj bral 
iz CD-ROMa (dokler nisem eksplicitno vkljucil using_dma za hdc).

-- 
Peace!
  Mkx

---- perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'