Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

buffer or not buffer

99 réponses
Avatar
Herve Autret
Bonjour,

Nous avons deux disques USB "My Passport" d'un To (modèles WDBACX0010BBL
et WDBACX0010BRD). J'ai une question sur le fonctionnement des buffers
disques.

Avec l'un ou l'autre disque, monté en ntfs-g3, je lance plusieurs fois la
commande suivante :
# time tar -C $repertoire_disque -c ./ > /dev/null

La 1ère fois, elle met environ 1'10" à se terminer

Un coup d'oeil sur le site de WDt me dit que le taux de transfert peut
atteindre 480Mo/s en USB-2, ce qui est le cas de mon système.
Déjà là, on dépasse la vitesse théorique de 50% !

Mais la 2ème fois, la commande prend 12", à la 3ème 5,2", puis 4.7", etc.

La comande du se comporte de la même manière ; 1'8" puis 3.7" en
enchaînant les appels avec un disque; mais 53" puis 13" avec l'autre.

Je n'ai que 2Go de RAM, il est impossible que les données des disques
soient bufferisées là. Quelqu'un pourrait me dire si cette évolution des
temps de transfert est normale et à quoi elle est dûe dans ce cas ?

à +
--
Hervé

10 réponses

1 2 3 4 5
Avatar
Luc.Habert.00__arjf
Herve Autret :

Un coup d'oeil sur le site de WDt me dit que le taux de transfert peut
atteindre 480Mo/s en USB-2,



Mb, pas Mo. Et il y a une proportion non négligeable de ces bits qui est
bouffée par le protocole, donc il faut diviser par plus de 10 pour obtenir
le débit utile maximal en Mo/s. Si ton disque arrive à cracher du 40Mo/s, tu
peux t'estimer content.

Avec l'un ou l'autre disque, monté en ntfs-g3, je lance plusieurs fois la
commande suivante :
# time tar -C $repertoire_disque -c ./ > /dev/null

La 1ère fois, elle met environ 1'10" à se terminer [snip] Déjà là, on
dépasse la vitesse théorique de 50% !



Je ne vois nulle part dans ton message d'indication de la taille cumulée des
fichiers du répertoire. Comme tu surestimais déjà la vitesse théorique d'un
facteur 10, je pense que ton erreur est à ce niveau.
Avatar
Herve Autret
Luc Habert :

Je ne vois nulle part dans ton message d'indication de la taille cumulée
des fichiers du répertoire. Comme tu surestimais déjà la vitesse
théorique d'un facteur 10, je pense que ton erreur est à ce niveau.



En fin de semaine et tout ça, c'est possible :
time du -s /mnt/sauv/
52237733 /mnt/sauv/

real 0m4.192s
user 0m0.128s
sys 0m0.875s

C'est bien autour de 52 Go, quand même ?
--
Hervé
Avatar
Luc.Habert.00__arjf
Herve Autret :

time du -s /mnt/sauv/
52237733 /mnt/sauv/

real 0m4.192s
user 0m0.128s
sys 0m0.875s

C'est bien autour de 52 Go, quand même ?



À moins que du n'affiche pas en ko (il y a des variables d'environnement à
la con qui influent dessus). Que donne "du -sk"?
Avatar
Stéphane Goujet
Le 18 Nov 2011 16:11:12 GMT,
Herve Autret a écrit :

time du -s /mnt/sauv/
52237733 /mnt/sauv/

real 0m4.192s
user 0m0.128s
sys 0m0.875s

C'est bien autour de 52 Go, quand même ?



Pas forcément. Faites "du -sk" (resp. "du -sm") pour être sûr d'avoir
le résultat en kio (resp. Mio).
Avatar
Herve Autret
On Fri, 18 Nov 2011 16:25:05 +0000, Luc Habert wrote:

Herve Autret :

time du -s /mnt/sauv/
52237733 /mnt/sauv/

real 0m4.192s
user 0m0.128s
sys 0m0.875s

C'est bien autour de 52 Go, quand même ?



À moins que du n'affiche pas en ko (il y a des variables d'environnement
à la con qui influent dessus). Que donne "du -sk"?



Je ne peux plus essayer avant lundi, néanmoins j'ai la réponse
(supposément). Cet après-midi j'avais lancé "du -s" sur une clef USB, la
réponse tournait entre 900Mo et un Go. J'ai emporté cette clef chez moi,
et "du -sk" donne 915840, contre 895 pour "du -sm".

J'ai peut-être le début du pourquoi. J'ai relancé différentes commandes,
en démontant et remontant la clef à chaque fois, sur un répertoire qui
tiendrait en taille dans /dev/shm :

En fait, à ce qu'il semble :
* du -s ne lirait pas le contenu des fichiers mais se contenterait de
lire les indications du superblock (6 ms)
* tar -c rep > fichier lit le contenu des fichiers (1160 ms)
* tar -c rep > /dev/null ne lirait que le superblock (7 ms)...

Ce dernier point m'embête : depuis quand un programme serait-il censé
savoir ce qui se passe derrière une redirection ?

** manips **
$ mount /mnt/usb
$ time du -sm /mnt/usb/rep
20 /mnt/usb/rep/

real 0m0.006s
user 0m0.000s
sys 0m0.002s

$ umount /mnt/usb && mount /mnt/usb
$ time tar -C /mnt/usb/rep/ -c ./ > /dev/shm/titi

real 0m1.161s
user 0m0.000s
sys 0m0.067s
$ umount /mnt/usb && mount /mnt/usb
$ time tar -C /mnt/usb/rep/ -c ./ > /dev/null

real 0m0.007s
user 0m0.001s
sys 0m0.002s
** manips **

à +
--
Hervé
Avatar
Nicolas George
Herve Autret , dans le message <4ec6db5f$0$3705$,
a écrit :
* du -s ne lirait pas le contenu des fichiers mais se contenterait de
lire les indications du superblock (6 ms)



Les inodes, surtout.

* tar -c rep > /dev/null ne lirait que le superblock (7 ms)...



Pareil, les inodes.

Ce dernier point m'embête : depuis quand un programme serait-il censé
savoir ce qui se passe derrière une redirection ?



Pour des informations élémentaires, comme savoir si c'est un vrai fichier,
un pipe ou un device (et dans ce dernier cas, quel device), depuis toujours.
Juste la plupart ne s'en soucient pas.
Avatar
Herve Autret
Bonjour,

Nicolas George :

lire les indications du superblock (6 ms)


Les inodes, surtout.



J'ai failli dire "catalogue", notez.

Ce dernier point m'embête : depuis quand un programme serait-il censé
savoir ce qui se passe derrière une redirection ?


Pour des informations élémentaires, comme savoir si c'est un vrai
fichier, un pipe ou un device (et dans ce dernier cas, quel device),
depuis toujours. Juste la plupart ne s'en soucient pas.



Par exemple : ls qui formate sa sortie différemment si la sortie est la
console ou une redirection ? Je ne sais même pas comment ça se passe ;
le programme peut obtenir du système les caractéristiques de son flux
sortie ? Un programme peut savoir s'il est redirigé vers /dev/null plutôt
que sur autre chose ? Je dirais : quid de l'organisation en couches du
système ?

Mais ce n'était pas ce que je voulais dire. Je ne pense pas que la
différence entre la redirection vers /dev/shm/fichier et vers /dev/null
soit telle qu'il faille 1 seconde de plus pour créer le fichier et le
remplir par rapport à ne rien faire, si les 20 Mo de données sont
transférés à chaque fois. Je dis ça, mais je ne sais pas le chiffrer.

J'ai refait quelques manips :
La différence entre rediriger 20 Mo depuis /dev/zero vers
/dev/shm/fichier et vers ~/tmp/fichier est insignifiante : encore un de
mes préjugés qui tombe à l'eau. Peut-être le temps d'appel des
bibliothèques qui créent le fichier est-il grand devant le temps
d'écriture sur le média ?

Avec la clef USB de 2 Go, il y a peu de différences entre
time dd if=/dev/sda > /dev/null (1'56")
et
time dd if=/dev/sda > /tmp/usb (2"1.425")

Par contre, je retrouve une différence entre
time tar -C /mnt/usb/ -c ./ > /tmp/tarusb (0'55.153" ; la clef contient
0.9Go : c'est cohérent avec dd)
et
time tar -C /mnt/usb/ -c ./ > /dev/null (0'0.225")

Bon ; il semble que tar puisse voir ce qu'il y a derrière les
redirections. Merci pour la leçon.
--
Hervé
Avatar
Nicolas George
Herve Autret , dans le message <4ec7a6f1$0$25897$,
a écrit :
Par exemple : ls qui formate sa sortie différemment si la sortie est la
console ou une redirection ?



Oui, par exemple.

Je ne sais même pas comment ça se passe ;
le programme peut obtenir du système les caractéristiques de son flux
sortie ?



Un programme peut savoir les caractéristiques de n'importe quel fichier
ouvert, le flux de sortie n'est que le fichier numéro 1.

Un programme peut savoir s'il est redirigé vers /dev/null plutôt
que sur autre chose ?



Oui, entre autres.

Je dirais : quid de l'organisation en couches du
système ?



Oui, quoi ?

Mais ce n'était pas ce que je voulais dire. Je ne pense pas que la
différence entre la redirection vers /dev/shm/fichier



Quelle mouche t'a piqué de vouloir aller écrire dans /dev/shm ?

Bon ; il semble que tar puisse voir ce qu'il y a derrière les
redirections.



C'est ce qu'on vient de dire.
Avatar
Herve Autret
Bonjour,

Nicolas George :

[]Je dirais : quid de l'organisation en couches du système ?


Oui, quoi ?



Les redirections ne délimitent pas une couche "étanche" pour les
programmes comme je le pensais, donc je disais rien.

Quelle mouche t'a piqué de vouloir aller écrire dans /dev/shm ?



Ben je m'étais dit qu'écrire dans un fichier en ram ou dans /dev/null
devait prendre à peu près le même temps ; du coup j'ai essayé -avec tar
encore une fois-. Et comme je n'ai pas expliqué ce que je faisais, ça
donnait un propos confus.

Bon ; il semble que tar puisse voir ce qu'il y a derrière les
redirections.



C'est ce qu'on vient de dire.



J'y croyais pas.
--
Hervé
Avatar
Luc.Habert.00__arjf
Nicolas George :

Un programme peut savoir s'il est redirigé vers /dev/null plutôt
que sur autre chose ?



Oui, entre autres.



Tu pourrais expliquer un peu quand meme.

Précisons: l'appel fstat permet d'obtenir pour un file descriptor pointant
vers un fichier les memes infos que l'appel stat sur le nom du fichier. En
particulier, on peut savoir qu'on pointe sur /dev/null en regardant le
st_rdev. Sous linux, on peut également regarder dans /proc/dev/fd.

Bon ; il semble que tar puisse voir ce qu'il y a derrière les
redirections.



C'est ce qu'on vient de dire.



Je me demande bien ce qui est passé par la tete du gars qui a décidé de s'en
servir, par contre.
1 2 3 4 5