Administrace komentářů

> dd testuje filesystem? Jasne, muzu to postvat na nejaky soubor na tom filesystemu,
> ale to ma nulovou vypovidaci hodnotu.

Proc myslite? Kdyz hrnete data z /dev/zero do souboru nad FS, tak otestujete prave surovou sekvencni pruchodnost do filesystemu. Pokud strihate HD video, tak tento udaj ma uzitkovou hodnotu docela dobrou Filesystem pridava do sekvencniho toku svoje vlastni seeky navic, takze sekvencni pruchodnost do FS bude oproti holemu blokovemu zarizeni mensi.

> Dobu seeku jsem zatim nezmeril vubec nicim.

Mam pocit, ze [ avg.seek = 1 / Tps ] : co vy na to?

Muj hddtest reportuje pocet svych read()/write() volani za sekundu. Mozna presnejsi je ale hodnota ziskana z iostatu (utilita z baliku sysstat), ten hlasi Tps na rozhrani s diskem. Pokud spustite hddtest -2 (nebo si pockate, az hddtest bez argumentu dojede do faze nahodnych pristupu), tak mate moznost pozorovat Tps pro "seek positions" generovane nahodnym generatorem. To je IMO nejobtiznejsi load, jaky se realne muze vyskytnout, treba pri zaplnenem filesystemu - pokud po disku nechcete prevazujici seekovani mezi dvema vzdalenymi partisnami, pristup na FAT FS s IO barierami apod. Hodnoty avg.seek pri nahodnem seekovani jsou dost pesimisticke

> Jde mi o tech 6 disku co mam, obavam se, jestli RAID-0 nebude mit obrovsky
> overhead prave v tom nez vsechny disky najedou tam kam maj.

Obecne u stripovanych poli to berte tak, ze [seek time celeho stripe setu] == [seek time nejpomalejsiho disku]. Cili nejpomalejsi disk = uzke hrdlo. Ale plati to jenom v pripade, ze potrebujete precist nebo zapsat cely stripe set naraz - tj. typicky pri operacich s paritou, nebo obecne pri transakci vetsi nez je stripe set size.

Konkretne u RAIDu 0 se nepocita zadna parita, takze cteni a zapis se chovaji cca stejne. Pokud je transakce mensi nez stripe size (a navic zarovnana dovnitr jednotliveho stripu), tak se zapis i cteni tykaji jedineho disku, a uplatni se pouze jeho individualni seek time. Obecne se uplatni seek time tech disku, kterych se tyka konkretni transakce...

Pri cteni celeho stripe setu (nebo jenom vice stripu vedle sebe) jednotlive disky seekuji a ctou paralelne, takze seek times se nescitaji - pro dokonceni transakce je rozhodujici seek time nejpomalejsiho disku, ostatni to proste "stihly rychleji".

Nejake slozitejsi interakce mezi seek times ruznych disku necekejte - krome toho uzkeho hrdla u vetsich transakci. Ted si nejsem jistej, jestli RAID nahodou nerozebere i zapisy celych stripe setu mezi jednotlive disky. Treba kdyz Areca inicializuje pole nulama (aspon nova SASova Areca), tak nektere disky dokonci inicializaci driv a nektere pozdeji - takze zjevne na sebe navzajem "necekaji"... Pokud by se RAID takto choval i s uzitecnymi daty, tak by pri zapisu to uzke hrdlo na pomalem disku vyniklo az po zaplneni WB cache RAIDu. Tim se dostavame k tomu, ze radic RAIDu muze cachovat "drive side" nebo "host side" transakce, nebo oboje adaptivne podle potreby - ale to je myslim uz jina pohadka, navic prakticky nedokumentovana...