Sziasztok!
A cp és mv Unix parancsokat kibővítettem egy másolási sorral. A Pythonban írt forrást bővebb leírással itt találjátok: https://github.com/jabbalaci/Copy-Queue . Szívesen veszek ötleteket/javaslatokat.
Üdv.:
Lac
- 5936 megtekintés
Hozzászólások
Miert jo a
(cp file1 /trash/movies/;cp file2 /trash/movies;mv file3 /trash/movies/)&
helyett a
cpq file1 /trash/movies/;cpq file2 /trash/movies/;mvq file3 /trash/movies/
?
- A hozzászóláshoz be kell jelentkezni
Megmondom miért: ha pl. 20 fájlt akarsz másolni 20 különböző helyről, akkor azt a Te módszereddel elég fárasztó lenne összeírni. De tegyük fel, hogy összeírtad és elindítottad, de utána rájössz, hogy "hoppá, valamit kihagytam". Ekkor vagy megvárod, míg befejezi, vagy konkurrens módon elindítasz egy új másolást ami viszont eléggé le fogja húzni a gépedet.
- A hozzászóláshoz be kell jelentkezni
$ echo "20 masodperces masolas"; sleep 20 &
20 masodperces masolas
[1] 24402
$ wait %1 ; echo "nem parhuzamos masolas indul"
[1]+ Done sleep 20
nem parhuzamos masolas indul
(Amúgy becsülöm a csináld magad hozzáállást.)
- A hozzászóláshoz be kell jelentkezni
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!
- A hozzászóláshoz be kell jelentkezni
Köszönöm szépen a részletes választ. Jelenleg úgy oldottam meg, hogy a kliens indítja el a szervert is. A szerver megnézi, hogy fut-e már egy szerver, s ha igen akkor kilép. Vagyis mindig csak egy szerver futhat. A szerver pedig kilép ha üressé válik a sor. Azért csináltam így, mert nem akartam egy szervert futtatni állandó jelleggel. Viszont ha a sorba nagyon gyorsan kerülnek be kisméretű fájlok, akkor gond lehet, ezért is tettem bele egy kis várakoztatást. Lehetne úgy is (ötlet), hogy továbbra is a kliens indítja a szervert, de a szerver nem lép ki egyből amint üressé válik a sor, hanem még percekig várakozik. A szervert viszont nem akarom állandóan futtatni, azt túlzásnak tartom. Csak akkor szeretném elindítani, amikor szükség van rá.
Tetszik a named pipe-os ötlet, ezen még gondolkodni fogok.
- A hozzászóláshoz be kell jelentkezni