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 ?
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.
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.
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.
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é
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/
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é
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"?
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"?
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).
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é
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 **
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é
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.
Herve Autret , dans le message <4ec6db5f$0$3705$426a74cc@news.free.fr>,
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.
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.
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é
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é
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é
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.
Herve Autret , dans le message <4ec7a6f1$0$25897$426a74cc@news.free.fr>,
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.
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.
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é
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.
[]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é
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.
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.
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.