A dd-t lehet e az alábbi módon használni?
A dd input-ja és output-ja nevesített vagy névtelen csövek (azaz a standard input és/vagy standard output). Az input és az outputjára külön-külön processz-ek írnak és olvasnak.
Vagyis 2 processz közötti adatcsatornát létesítek csövekkel és a dd segítségével. Ezt eddig simán meg tudom csinálni.
Amit nem tudok, hogy hogyan lehet úgy megcsinálni vagy egyáltalán lehet e dd-vel, hogy amíg a termelő írhasson amikor akar és ne kelljen várnia a fogyasztóra és természetesen a fogyasztó is tudjon olvasni és ne kelljen várnia a termelőre. Ha lenne erre 50 mega puffer az bőven elég lenne a célra (igazából kevesebb is elég lenne, de maradjunk az 50 megánál).
Az alábbi működik ha nem nevesített csövet hanem sima fájlt használok:
foo1 > file &
sleep 3
dd if=file | foo2
Ahol foo1 a termelő mely néhány 100 kilobit/sec sebességgel termel. A foo2 a fogyasztó mely szintén ilyen sebességgel fogyaszt, de a termelés és a fogyasztás változó bitsebességű.
Egyébként videostream megy át csöveken a médialejátszónak, de nem akarom folyamatosan menteni a háttértárra ideiglenesen sem.
Ha teljesen csak csövekkel próbálkoztam akkor instabil max fél percig ment úgy. Ha ideiglenes fájlba rakom akkor stabilan működik.
válasza: válasza:Ha nem akarod menteni a háttértárra akkor miért dd-vel akarod megoldani? Memóriába való pufferelésre vannak egyébként programok, pl. buffer vagy mbuffer.
cat /dev/urandom | mbuffer -m 50M | cat
Első folyamat írja a buffert, a másik folyamat pedig olvassa. Nevesített csővezetékekkel is meg lehet hasonlóan oldani.
@09:01
Nem épp egészen mindegy. Ha memóriába van akkor minek írjam tele az egész ramdisk-et, ha az általam mondott 50 mega memória bőven sok hozzá?
"Ha nem akarod menteni a háttértárra akkor miért dd-vel akarod megoldani?"
Mert ezt használtam sok elég mindenre és be lehet állítani neki is pufferméretet. Nem egészen úgy pufferel mint kéne ez esetben. Azt hittem dd-vel lehet megoldani.
Nem akartam elkapkodni a választ ezt a mbuffer-t felraktam (sajna forrásból kellett lefordítanom amitől mindig félek hogy nem fog lefordulni, de szerencsére sikerült). Több mint 6 óra tesztelés után tökéletesen működik.
Nagyon köszönöm ment a zöld kéz.
válasza:dd-t is lehet hasonlóan használni de a dd direkt lemezírásra/olvasásra lett kitalálva és úgy is lett kialakítva, míg a buffer és mbuffer programok memóriaírásra/olvasásra vannak. Mint olyanok, a beállítási lehetőségeik és működésük is más. A dd estében a puffert a blokkmérettel adod meg, de a működése egy kicsit más. Itt a puffert az inputstream megtölti, aztán az inputstream blokkolva lesz amíg a puffer ki nem ürül, azaz teljes egészében át nem kerül az outputstreamre! Ezután az outputstream blokkolódik amíg meg nem telik újra a puffer, ez az az idő amikor jön a "szaggatás". Gyakorlatban ez kihasználja a lemezcache-t is írásnál és a lemezblokkokat teljes egészében fel tudja használni. Nem tudom pontosan az if-es változat miért működik az stdin-es pedig miért nem, de valószínűleg azért mert az if közvetlenül a lemezből a memóriába olvas és cachel CPU-tól függetlenül, az stdin pedig keresztülmegy a CPU-n ezért várnia kell a sorára. Implementáció és kernel függő. Ha azt szeretnéd hogy ne kelljen várni a puffer feltöltésére és kiürítésére akkor tudnál írni valami ilyesmit:
proc1 | dd bs=1 count=50000000 | proc2
Érezhető azért hogy ebben mekkora overhead van, bájtonként olvassa és írja így a lemezt/memóriát.. Valószínűleg olyan lassú lenne hogy azt a pár 100kbit/s sebességet se bírná (de az stdin is bájtonként érkezik, úgyhogy lehet hogy így menne is). Érdemes azért a dd-t arra használni amire ki lett találva, és ez pedig nem a memóriába való pufferelés, arra ott van a buffer/mbuffer)
Nem tudom milyen beállításokkal próbálkoztál, de ha gondolod, teszteld kisebb blokkmérettel, lehet hogy működik de ez csak egy erős tipp:
proc1 | dd bs=1k count=50000 | proc2
proc1 | dd bs=50M | proc2
proc1 | dd ibs=50M | proc2
dd if=namedpipe bs=50M | proc2
Meg több különböző ibs obs értékekkel is. Meg úgy is hogy
proc1 | dd bs=50M |
{
sleep 3
proc2
}
oda raktam be várakozást, 3 meg 5 másodperynyit. Ha nem oda raktam akkor a proc1-et indítottam külön szálba nevesített csőbe írt majd sleep 5 majd a dd-vel megnyitottam.
Volt olyan is, hogy dd-vel if az egyik nevesített csőbe olvasott az of egy másikba írt.
Volt a oflag=dsync kapcsolója is meg mindenféle kapcsolóit próbálgattam, gyakorlatilag amiről ordít hogy felesleges lenne kipróbálni pl a skip, azokat leszámítva a man-ban leírt összes kapcsolóval kipróbáltam, ha véletlen nem hagytam ki valamelyiket.
Persze nálam a proc1 az igazából nem egy process hanem valójában több, de tulajdonképpen egy block.
Amit te írtál azt most kipróbáltam, de azzal sem viszi. Ránézésre az azért nem jó mert van benne count mely (ibs méretű) kvázi bs mérető count darab blokkot másol.
Kapcsolódó kérdések:
Minden jog fenntartva © 2024, www.gyakorikerdesek.hu
GYIK | Szabályzat | Jogi nyilatkozat | Adatvédelem | Cookie beállítások | WebMinute Kft. | Facebook | Kapcsolat: info(kukac)gyakorikerdesek.hu
Ha kifogással szeretne élni valamely tartalommal kapcsolatban, kérjük jelezze e-mailes elérhetőségünkön!