On Wed, 2005-12-28 at 01:38 +0200, Liviu Daia wrote: > Nici asta nu am negat ca se intampla. Atat timp cat st_blksize >= > BUFSIZ, asta este o optimizare. Problema apare doar daca st_blksize > < BUFSIZ. Da-mi un exemplu de filesystem cu st_blksize < 1 KB sub un > *BSD, si mi-ai demonstrat ca problema nu e specifica Linux.
msdosfs si hfs in Freebsd suporta blocuri de 512 - http://www.google.com/search?q=msdosfs+%22minimum+block+size%22 http://people.freebsd.org/~yar/hfs/kernel.html Probabil si alte sisteme de fisiere accepta blocuri < 1KB dar asta nici nu mi se pare foarte relevant. O biblioteca sistem nu are voie sa functioneze pe supozitii privind plaja de valori valide pentru parametrii din alte componente (kernel/fs in cazul de fata) din principiu. Conditia POSIX ar trebui impusa explicit (in caz ca exista) si nu implicit (facem BUFSIZ == 1KB la plezneala si pe urma ne rugam sa nu apara sisteme de fisiere cu st_blksize mai mic). > > Teoria ta (ultima dintre ele) era ca segmentarea se produce mai jos > > de glibc/stdio (adica in kernel, pentru ca intre stdio si apelurile > > sistem read()/write() nu mai intervine nici un buffer). > > Unde am spus eu asta? E o implicatie din: "Afirmatia mea e ca fisierele se scriu pe disc in chunk-uri avand dimensiunea de la (3), fara legatura cu (1) sau (2)." Daca segmentarea nu e un efect al bufferelor stdio (2) atunci nu mai ramane decat kernelul, nu? > > Asta e usor de invalidat folosind strace care arata clar ca datele > > sunt segmentate _inainte_ de apelul sistem write(), adica in > > glibc/stdio: > > > > [EMAIL PROTECTED] ~]# strace tcpdump -i wlan0 2>&1 >/tmp/tst | grep > > "write(1" > > write(1, "14:00:50.224841 IP 192.168.77.20"..., 4096) = 4096 > > write(1, "amp 10145173 2190099611>\n14:00:5"..., 4096) = 4096 > > write(1, "7.202.33219: P 2474:2565(91) ack"..., 4096) = 4096 > > write(1, "estamp 10147075 2190101472>\n14:0"..., 4096) = 4096 > > write(1, "14:00:20.833800 IP 192.168.77.202"..., 4096) = 4096 > > write(1, "maps: . ack 6743 win 16022 <nop,"..., 4096) = 4096 > > write(1, " win 16022 <nop,nop,timestamp 10"..., 4096) = 4096 > > Si ce arata asta din ce nu stiam pana acum? Ca afirmatia ta de mai sus e gresita si segmentarea se produce in glibc/stdio/(2) inainte ca datele sa fie aruncate in curtea kernelului. Ma rog, poate n-am inteles eu ce vrei sa spui acolo. > Teoria mea e ca asta e un bug in glibc, pentru ca exista cazuri in > care st_blksize < BUFSIZ. Iar despre asta nu imi poti demonstra ca nu e > asa cu citate din codul glibc, ci doar cu citate din standarde. Dar iti pot demonstra ca si celelalte libc-uri opereaza la fel, fara a impune regula "BUFSIZ e minim". Iar asta are 2 explicatii posibile: sau toate libc-urile se pisa pe POSIX, sau POSIX nu stipuleaza ca bufferul sa fie minim BUFSIZ. > > > http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/stdio/makebuf.c?rev=1.7&content-type=text/x-cvsweb-markup ... > $ grep __SSTR /usr/include/stdio.h > #define __SSTR 0x0200 /* this is an sprintf/snprintf string */ ...deci? e sau nu o buba in implementarea OpenBSD? Repet: cand/daca __SSTR e setat, size/bufsize ramane neinitializat si va produce balarii in __smakebuf(). > ... Numai ca acelasi rezultat se obtine si sub Linux, ceea ce dupa > explicatia mea nu ar trebui sa se intample. Ma vad deci nevoit sa iti > dau dreptate in ceea ce priveste explicatia dimensiunii chunk-ului: > explicatia ta e corecta, iar a mea nu. Thanks, mi-ai salvat degetele :) > Ramane insa afirmatia despre buffer-ul mai mic decat BUFSIZ: sustin > in continuare ca aceasta implementare e un bug. Aici nu te contrazic direct pentru ca nu sunt familiarizat in halul asta cu POSIX. Dar daca e adevarat (POSIX impune un buffer de minim BUFSIZ bytes), atunci nu numai glibc sufera de acest bug ci si toate libc-urile BSD pentru ca niciuna nu garanteaza explicit conditia respectiva. -- fm _______________________________________________ RLUG mailing list [email protected] http://lists.lug.ro/mailman/listinfo/rlug
