---------- Forwarded message ----------
Date: Thu, 14 Jun 2001 10:46:29 +0200 (MEST)
From: Marc SCHAEFER <[EMAIL PROTECTED]>
To: F�lix Hauri <[EMAIL PROTECTED]>
On Wed, 13 Jun 2001, F�lix Hauri wrote:
> $ cat vmlinuz.tst /dev/zero |dd of=truc28 bs=2048 count=336
> ne marche pas, tandis que
> $ cat vmlinuz.tst /dev/zero |dd of=truc28 ibs=1 obs=2048 \
count=$((2048*336))
> marche mieux, mais consomme �nh�rmement de proc et de temps:(
Probl�me: cat va vraisemblablement envoyer au plus des blocks de 4096
bytes (PIPES_SIZ), jusqu'� la fin du fichier, et l� si le fichier n'a pas
une taille multiple de 4096, il y aura un bloc ``incomplet'', puis
ouverture de /dev/zero et envoi de blocks usuels.
read(3, "n\376>\276\301\2744\276\327\\~+\342\214yY\374\272\271\374"...,
4096) = 2087
write(1, "n\376>\276\301\2744\276\327\\~+\342\214yY\374\272\271\374"...,
2087) = 2087
read(3, "", 4096)
close(3) = 0
open("/dev/zero", O_RDONLY|0x8000) = 3
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096)
= 4096
write(1, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
4096) = 4096
En bref il faut dire � dd d'accepter une taille quelconque d'I/O en entr�e
(mais au plus 4096 bytes), et de rebufferiser le tout en sortie avec une
taille correcte sp�cifi�e (multiple de 512 bytes si taille de I/O tape 512
fixe; sinon taille constante p.ex. 4096 bytes ou 32kbytes si mode
variable, ie setblk 0), avec au pire un bloc de taille inf�rieur pour le
DERNIER bloc de la taille (en mode variable), ou sinon, en mode fixe 512,
ajouter des NULs.
PS: ta question de la voiture:
count=BLOCKS
copy only BLOCKS *input* blocks
Reprenons un petit exemple avec
-rw-r--r-- 1 schaefer schaefer 387 Jun 14 10:29 test_file
-rw-r--r-- 1 schaefer schaefer 4096 Jun 14 10:30 test_file_2
et strace -e 'read,write' cat test_file test_file_2 > /dev/null
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\244\213"...,
4096) = 4096 --- lecture d'une biblioth�que, ne pas consid�rer.
read(3, "\270\300\7\216\330\270\0\220\216\300\271\0\1)\366)\377"..., 4096)
= 387
write(1, "\270\300\7\216\330\270\0\220\216\300\271\0\1)\366)\377"..., 387)
= 387
read(3, "", 4096) = 0
read(3, "\270\300\7\216\330\270\0\220\216\300\271\0\1)\366)\377"..., 4096)
= 4096
write(1, "\270\300\7\216\330\270\0\220\216\300\271\0\1)\366)\377"...,
4096) = 4096
read(3, "", 4096) = 0
Donc lecture de 387 bytes, puis �criture de ces bytes, lecture de 4096,
�criture idem, puis EOF. (le code de retour, = truc, sur la droite est le
nombre de bytes r�ellement lus; la valeur dans la parenth�se le max du
buffer).
Pour bien comprendre, exp�rimente un peu avec:
cat test_file test_file_2 | strace -e 'read,write' dd of=/dev/null
et ensuite ajoute un bs=1024: tu verras que les I/Os font au plus 1024,
mais quand un I/O de 387 arrive, il sort en write de 387. Maintenant, si
tu mets obs=1024, tu remarques qu'un nombre certains de read() sont
n�cessaires afin de remplir le buffer write().
Maintenant, � travers un pipe, compare avec obs=4096 et obs=8192, avec un
fichier test_file_2 p.ex. 16384 bytes p.ex. (sur ix86, car sur Alpha,
PIP_SIZE est probablement 8k, taille de page MMU de ce processeur).
Utiliser ulimit -p pour savoir (unit�: sp�cifi�e dans ulimit -a, 8 x 512
bytes chez moi).
cat test_file test_file_2 | strace -e 'read,write' dd obs=8192 \
| cat > /dev/null
cat test_file test_file_2 | dd obs=8192 | strace -e 'read,write' cat > /dev/null
Conclusion: le dd a l'impression de pouvoir �crire 8kb, mais de l'autre
c�t� on voit 4kb seulement. Rappelons que toute �criture inf�rieure �
PIP_SIZE est garantie atomique sous UNIX -> �criture non atomique.
Donc si N processus sont connect�s via un pipe UNIX � un processus
serveur, il y aura entrem�lement des donn�es pour taille > 4096 bytes.
Apache utilise cette propri�t� pour rendre ses �critures atomiques de
fa�on efficace.
Remarque qu'on n'a pas sp�cifi� count, et d'ailleurs on a meilleur temps,
car c'est le input block count, pas en bytes, mais en blocks,
�ventuellement partiels!
PS: tu peux poster mon mail, ou un r�sum� sur la ml.
(ndfwdr: C'est fait;-)
--
F�lix Hauri - <[EMAIL PROTECTED]> - http://www.f-hauri.ch
--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question. Ouais, pour se d�sabonner aussi.
