Dragos Chiriac scria la data de 23 Decembrie 2005:
> 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.
Ok, m-ai facut curios, asa ca am cercetat putin ambele chestiuni:
(1) Output-ul lui tee este intr-adevar unbuffered, atat in specificatii
(Single UNIX Specification v3), cat si in practica (GNU coreutils
5.2.1 sub Linux, Base sub *BSD).
(2) Ceea ce am spus mai inainte despre buffering in stdio(3) e adevarat,
dar comiterea datelor pe disc se face si ea buffer-at. De acolo
vine numarul magic 4096, vezi mai jos.
[...]
> > 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.
M-am uitat (in diagonala, dar nu cred ca mi-a scapat ceva) prin
sursele Bash 3.1. Nu e, cum spuneam, nici o diferenta intre ">file" si
"1>file".
[...]
> 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.
La mine nu se intampla asta. In ambele cazuri output-ul e in
chunk-uri de exact 4096 (sub Linux).
> 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.
Cum spuneam mai sus, asta vine de la faptul ca write(2) este de
fapt si el buffer-at (daca fisierul in care scrii nu a fost deschis cu
flag-ul O_SYNC). Dimensiunea acestui buffer poate fi aflata din campul
st_blksize din stat:
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>
main ()
{
struct stat st;
if (fstat (fileno (stdout), &st))
{
perror ("stat");
exit (1);
}
fprintf (stderr, "%d\n", st.st_blksize);
exit (0);
}
Evident, sub Linux valoarea asta este 4096.
Interesant e ca sub Linux valoarea nu depinde de faptul ca STDOUT
este un fisier pe disc sau altceva, in timp ce sub *BSD valoarea este de
16 KB pentru fisiere pe disc (sub filesystem UFS si UFS2) si de 64 KB
pentru pipe-uri si device-uri de tip caracter (de exemplu tty-uri).
Mai ramane totusi o problema: datele sunt comise pe disc inainte sa
se umple buffer-ul de 8 KB al lui stdio(3). Fenomenul este specific
Linux-ului, si pare a fi un bug / o optimizare in glibc. Optimizare,
pentru ca st_blksize este dimensiunea optima pe care o poate avea
buffer-ul stdio(3) (in cazul asta se evita efectele neplacute care apar
prin double buffering).
> 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).
Ok, nu voi mai scrie adrese in clar pe lista.
> Sarbatori fericite,
Multumesc, la fel tie si restului de colistasi.
Salutari,
Liviu Daia
--
Dr. Liviu Daia http://www.imar.ro/~daia
_______________________________________________
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug
