Liviu Daia wrote:
Dragos Chiriac scria la data de 23 Decembrie 2005:
[...]
Cerere de iluminare.
Ok, atunci pun si eu o intrebare. Inteleg ca faptul ca outputu se
scoate in chunks de 4096 de bytes
Cum spuneam, 8192.
~# tcpdump -ttttnnq -i eth0 port not 22 | tee > ./dat
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
60 packets captured
121 packets received by filter
0 packets dropped by kernel
~# ls -la ./dat
-rw-r--r-- 1 root root 4096 Dec 23 20:55 ./dat
saraca masina are un trafic de cam 3-12 pk pe secunda (fara ssh-ul
meu). sa fie de la tee ? parca totusi tineam minte ca tee scoate
unbuffered.
(daca nu scrii 1> in loc de > :P) se datoreaza unui pipe ceva.
Nici o legatura. Cand redirectezi output-ul catre ceva care nu
seamana a tty, shell-ul cheama fork(2), cheama dup2(2) ca sa faca
redirectarea, face rezultatul fully buffered, apoi exec(3)-uieste
procesul respectiv.
bine de stiut.
Fara nici o gluma, chiar ma intereseaza, cum si de ce ? si de ce se
intampla faza cu > vs 1> ?. (si eu am ramas siderat cand am vazut
prima data. Si la diverse chestii care folosesc tee tot asa tre sa fac
ca sa "mearga", si culmea, merge).
La aceasta intrebare nu vei putea primi un raspuns rational decat
in momentul in care vei putea da un exemplu, reproductibil si pe alte
sisteme decat al tau, de caz in care se intampla asta.
Stiu ca calculatoarele nu sunt voodoo, de asta nu am inteles-o prea bine
niciodata. Iata cum/de ce pana acu am avut impresia ca "_face rezultatul
fully buffered_, apoi exec(3)" decat daca scrii 1>. Aproape m-ai
convisns sa reinstalez janghina. poate am eu ceva wrong. o sa incerc si
pe alte sisteme. Pacat ca restu trebii si-l face extraordinar.
si cealalta intrebare humm, de ce tcpdump | grep merge coerent si
tcpdump| less de exemplu merge tot in chunks. Sunt sigur ca exista o
explicatie. Probabil tu o stii, si as fi recunscator sa ma lamuresti
si pe mine.
Simplu: nu se intampla asta, din punctul de vedere al buffering-ului
nu e nici o diferenta. Cum ai masurat, ca sa tragi concluzia ca e o
diferenta?
Daca ai facut asta ochioscopic, o posibila explicatie ar putea fi ca
ai lansat tcpdump fara optiunea "-n", cu rezultatul ca la prima lansare
ai asteptat dupa DNS, iar la a doua raspunsurile DNS-ului erau deja in
cache...
folosesc tcpdump -ttttnnq de obicei. nu-mi plac porturile scrise "cu
litere" si nici timestampuri ca sa ai la ce munci cand vrei sa vazi la
ce ora se intampla nu stiu ce. cand dau less imi apare sacadat, cand dau
grep curge linistit. Sa fie si asta de la less nu de la tcpdump ? ma
refer aici la -n activ si ac trafic ca mai sus. culmea e ca de nervi am
luat cu mousu din less dupa primu chunk. surpriza, 4096 :). Dap, m-am
uitat si eu acum prin alea, si te cred pe cuvant cu 8k, dar de unde ma
urmareste atunci 4096le asta, mama lui.
De asemenea sunt curios care e diferenta dinte exit si _exit la nivel
ceva mai mult decat _exit face quick termination procedures, in timp
ce exit le face complete. in rest descrierile sunt identice. de asta
pt mine in general exit, _exit sunt acelasi lucru. In principiu ce e
ala "quick" ? Macar mai invat si io ceva, cat ma dau pe liste.
Pentru asta iti recomand fie un sistem cu man pages mai bine scrise,
fie o carte de UNIX. Cum ar fi:
Stevens, W.R. - "Advanced Programming in the UNIX Environment",
Addison-Wesley, Reading, Massachusetts, 1997.
Cu putina creativitate o poti gasi si pe Internet, sub forma de PDF.
mersic. o s-o caut.
Salutari,
Liviu Daia
offtopic - vezi ca reply-ul tau contine adresele de mail in clar :(.
"Dragos Chiriac <dragosxxxxxsecured.ro> scria la data de 23 Decembrie
2005:". Pleaseee, lasa doar numele, din motive obiective. Mersic inca o
data (mai ales pt rabdare).
Sarbatori fericite,
Dragos
_______________________________________________
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug
