Rychlost filesystemu

Petr Simek psimek na jcu.cz
Neděle Září 3 22:38:19 CEST 2006


On Sun, 3 Sep 2006, Pavel Kankovsky wrote:

> On Tue, 29 Aug 2006, Petr Simek wrote:
>
> > Pokud ovsem pracuju s delkou bloku 512B (coz se mi pro pasku hodi vic)
> > tak uz to tak neni . dd uplne selhava, misto minuty trva prenost toho
> > 2.5GB souboru pet minut , funguje pouze cat . A tomu to trva z pasky
> > na disk asi 65 vterin ale z pasky do /dev/null 75 vterin.
>
> Primo: z pásky nemůžete číst bloky takové délky, jak Vás zrovna napadne.
> Sémantika páskového I/O je dost komplikovaná, ve které ještě podivně
> interaguje délka bloku nastavená na zařízení (mt setblk) a délka bloku
> používaná při čtení a zápisu.

Ehm to je mi jasne. Nastavim na pasce velikost bloku 512B a dd s bs=512
jede mnohem (5x) pomaleji nez cat. Soubory na pasce jsou pochopitelne
ulozeny s touto velikosti bloku, jinak to nefunguje.

> Navíc si nemyslím, že je dobrý nápad používat pro pásku krátkou délku
> bloku. Už jen z toho důvodu, že meziblokové mezery spotřebovávají nějaký
> prostor na pásce. Moje zkušenost (s AIT, YMMV) je taková, že při použití
> bloků délky 512 bajtů lze přijít i o dobrých 10 % kapacity pásky.

To je mozne, vyhodou je ze muzu primo najet na soubor na pasce v tar
zaloze. Kdyz pouziju vetsi velikost bloku zavedu si tim dalsi mezivrstvu
v ramci ktere se musim pohybovat.

> Secundo: jak víte, s jakým blokem (pokud vůbec nějakým <g>) pracuje cat,
> že jeho výsledky umisťujete pod "délku bloku 512 bajtů"?

To nevim, ale pokud na pasce nastavim jinou velikost bloku nez jakou to
pak zkusim cist/psat tak se ten proces zakousne. Tedy soudim ze to bude
asi tech 512B.

> Tertio: nepochlubil jste se, jak dlouho trvalo dd (s blokem 10 KiB)
> v absolutních hodnotách, takže sice víme, že do /dev/zero to trvalo
> polovinu toho, co na disk, ale nevíme, v jakém je to vztahu s těmi 75
> resp. 65 sekundami, co dosáhnul cat. Pokud se to zpětně pokusím odvodit
> z uvedených údajů (délka souboru 2,5 GB, rychlost 84 MB/s), tak mi
> vychází, že do /dev/zero dd přeneslo data za cca 30 sekund, zatímco na
> disk to trvalo cca 60 sekund. Je možné, že cat četl z pásky tak, že se to

Odhaduje to to spravne.

> četlo dvakrát pomaleji (bez ohledu na to, kam se to zapisovalo, prostě
> zápis na disk už nebyl potenciální bottleneck), takže v obou případech
> vyšlo něco málo přes 60 sekund. To, že to do souboru vyšlo přece jen o
> něco rychleji než na disk, je divná věc, možná v tom hraje roli nějaká
> umělá inteligence v cat, možná bufferování výstupu (je možné, dokonce
> pravděpodobné, že se při výstupu do souboru cat chová trochu
> jinak, než při výstupu do zařízení).

Mozna. Akceptuji ze paska pracuje pomaleji pri velikosti bloku 512B oproti
bloku 10240B, to je logicke. Co mi vrta hlavou je rychlejsi prenos do
souboru nez do /dev/null, to uz logicke neni, tedy aspon jak ja chapu
/dev/null a vzhledem k mym pokusum prenaseni dat z disku do /dev/null a
z /dev/zero do /dev/null kde to bezelo opravdu svizne. Co take nechapu
je, ze dd pri 10240B bloku s paskou pracuje ocekavanou rychlosti kdezto
pri 512B bloku vykonostne naprosto selhava. To jsou takove zahady, ale
abych pravdu rekl, uz neocekavam ze na ne zde naleznu vysvetleni. Proste
to tak je.

Pridal bych jeste jednu zahadu - mam v masine radic Adaptec 29320A a
procesor Intel P4/Xeon (dualcore). Nepodarilo se mi na to nainstalovat
Centos pri zastrcenem radici. Ty bootovaci skripty se kously pri
natahovani toho modulu aic79xx (lost irq 9 nebo neco podobneho to psalo).
Po instalaci kdyz uz to bezelo na smp kernelu to funguje dobre. Nepomohlo
ani vypnout v BIOSu dualprocesing. Jedine co se mi na tom podarilo
nainstalovat rovnou byl Ubuntu, ale pravdepodobne proto, ze server verze
ma smp kernel jiz v instalatoru. Zkousel jsem si stahnout a prelozit
nejnovejsi kernel rady 2.6 a pokud jsem ho prekladal s podporou smp tak
OK, kdyz jsme ji vypnul tak se mi kousaly boot skripty, protoze ten modul
aic79xx se pri zavadeni kousnul s chybovou hlaskou.


> --Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]


*------------------------------------------------------------------------*
|                          Petr Simek   APS JU                           |
|                             psimek na jcu.cz                              |
*------------------------------------------------------------------------*



Další informace o konferenci Linux