az alapotlet kivallo.
A diszk IO optimalizacion igen sokat lehet nyerni vagy vesziteni.
Alapesetben azt csinalja a linux IO utemezoje, hogy kezel egy queue-t a varakozo IO muveletekrol. Ezt sorbarendezi, hogy minel kevesebb legyen az seek, es minel nagyobb elemi IO muveleteket lehessen kuldeni a diszk iranyaba. Ha ez a queue eleg nagy, akkor a linux io alrendszere eleg jol tud mukodni. Termeszetesen, haz io queue merettel megegyezo szamu konkurens random kerest kap, akkor nem igen tud mit optimalizalni rajta.
Azt is lehetne mondani, hogy kieves/kicsiny szamu parhuzamos cp/mv eseten a queue optimalizaciot elvegzi a linux IO utemezoje maga, azonban nagyszamu/nagy file esetben lehet javitani a dolgon.
A konkret megvalositas kritikaja:
- a cp es az mv alap oprendszer cucc. Rendkivul fontos, hogy jol mukodjenek.
Emiatt azt szoktuk csinalni, hogy uid==0 eseten meghivjuk (exec) az eredeti utilityt. A root (es a neveben futo oprendszer) az menjen a maga modjan. Peldaul ha betelt az altalad hasznalt queue dir, akkor nem lehet arrol a particiorol elmasolni filet, fancy ;-)
- az apro file-ok altalaban inode szam szerint sorakoznak a diszken. Nagyobb sebesseg erheto el, ha a queue inode szam szerint sorbarendezi a vegrehajtando feladatot, es ugy vegzi el. Ez foleg rengeteg apro cucc eseten hasznos.
- kulon queue kellene diszkenkent. Pontosabban kulon queue kellene diszkparonkent :-) hogy mehessen egyszerre masolas a /dev/sda -rol az sdb -re, es az sdc-rol az sdd-re. Ok, ezt sokkal nehezebb implementalni, mint amennyit hoz a konyhara.
- nagyon nem jo otlet, hogy plusz file muveletet hasznalsz (a queue file-ban van megvalositva). Az altalad sleep(0.05) -tel foltozott race condition azert van, mert elofordul, hogy a kliens eppen menet kozben tart a atmeneti script felirasanal, amikor a szerver mar beleolvas(-na). Mondjuk legegyszerubben named-pipe-pal (man mkfifo) lehetne megvalositani: a daemon figyel egy named-pipe -n, abbol olvassa a parancsokat. A kliens szigoruan egyetlen muvelettel ir a named pipe-ba, azt a daemon a leheto leghamarabb (asszonkron modon) kiolvassa, egy belso memoriaban implementalt queue-ban orizgeti, amig vegre nem tudja hajtani. Mondjuk ekkor a daemont valahogy tobbszalura vagy asszinkronra kell megirni.
- ha asszinkron, queue rendszeru muveletet csinalsz, akkor mindig egyszerre ket dolgot kell implementalni: submit, wait. Vagyis kell egy program, ami pont addig var, maig keszen nem lesz a feladat. Ha scriptbol hasznalod, szukseg lesz ra. (pelda: cp a /mnt/; umount /mnt; ide elkellene egy varakozas. )
Mindent osszefoglalva, ha ez az elso queue megvalositasod, akkor nagyon szep munka. Ha ez az elso asszonkron IO megvalositasod, akkor is. Ha pedig ez az elso kliens-szerver modon leprogramozott barmid, akkor kifejezetten nagyon szep eredmeny!