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 ?
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.
Ah ? pas de ça chez moi. Néanmoins, je vois le principe :
Si pan a le pid 2457 : $ file /proc/2457/fd/0 /proc/2457/fd/0: symbolic link to `/dev/tty1'
Nickel, merci pour le tuyau.
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.
J'ai utilisé tar sur Solaris il y a quelques années et par défaut il recherchait une bande dans /dev. Le ou les gens en question ont dû simplement adapter le code existant par jeu, par goût ou je ne sais quoi.
à + -- Hervé
Bonjour,
Luc Habert :
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.
Ah ? pas de ça chez moi. Néanmoins, je vois le principe :
Si pan a le pid 2457 :
$ file /proc/2457/fd/0
/proc/2457/fd/0: symbolic link to `/dev/tty1'
Nickel, merci pour le tuyau.
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.
J'ai utilisé tar sur Solaris il y a quelques années et par défaut il
recherchait une bande dans /dev. Le ou les gens en question ont dû
simplement adapter le code existant par jeu, par goût ou je ne sais quoi.
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.
Ah ? pas de ça chez moi. Néanmoins, je vois le principe :
Si pan a le pid 2457 : $ file /proc/2457/fd/0 /proc/2457/fd/0: symbolic link to `/dev/tty1'
Nickel, merci pour le tuyau.
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.
J'ai utilisé tar sur Solaris il y a quelques années et par défaut il recherchait une bande dans /dev. Le ou les gens en question ont dû simplement adapter le code existant par jeu, par goût ou je ne sais quoi.
à + -- Hervé
Nicolas George
Herve Autret , dans le message <4eccdaa6$0$3701$, a écrit :
C'est la raison de ta question que je ne comprends pas.
Mais selon toi, un répertoire qui à la permission 'sticky bit' activée, et qui est aussi autorisé en écriture a tout le monde, ne devrait pas servir.
Alors, comment expliquer que /dev/shm soit communément utilisé en tant que système de fichiers tmpfs, et que dans certains [cas|distributions], /tmp soit un montage pur et simple de /dev/shm ?
Mais puisque tu sembles connaitre les raisons qui font qu'on ne doit pas utiliser /dev/shm pour y stocker des fichiers, nous te serions tous reconnaissants de partager avec nous ton savoir.
-- Le mode sans échec de Windows est la preuve que son mode normal est un échec !
SONY : It only does everything ... until we remove ! PS3 Firmware update 3.21 : The first software update which downgrade !
Le 23/11/2011 13:06, Nicolas George a écrit :
Herve Autret , dans le message <4eccdaa6$0$3701$426a34cc@news.free.fr>,
a écrit :
C'est la raison de ta question que je ne comprends pas.
Mais selon toi, un répertoire qui à la permission 'sticky bit' activée,
et qui est aussi autorisé en écriture a tout le monde, ne devrait pas
servir.
Alors, comment expliquer que /dev/shm soit communément utilisé en tant
que système de fichiers tmpfs, et que dans certains [cas|distributions],
/tmp soit un montage pur et simple de /dev/shm ?
Mais puisque tu sembles connaitre les raisons qui font qu'on ne doit pas
utiliser /dev/shm pour y stocker des fichiers, nous te serions tous
reconnaissants de partager avec nous ton savoir.
--
Le mode sans échec de Windows est la preuve que son
mode normal est un échec !
SONY : It only does everything ... until we remove !
PS3 Firmware update 3.21 :
The first software update which downgrade !
Mais selon toi, un répertoire qui à la permission 'sticky bit' activée, et qui est aussi autorisé en écriture a tout le monde, ne devrait pas servir.
Alors, comment expliquer que /dev/shm soit communément utilisé en tant que système de fichiers tmpfs, et que dans certains [cas|distributions], /tmp soit un montage pur et simple de /dev/shm ?
Mais puisque tu sembles connaitre les raisons qui font qu'on ne doit pas utiliser /dev/shm pour y stocker des fichiers, nous te serions tous reconnaissants de partager avec nous ton savoir.
-- Le mode sans échec de Windows est la preuve que son mode normal est un échec !
SONY : It only does everything ... until we remove ! PS3 Firmware update 3.21 : The first software update which downgrade !
Herve Autret
Luc Habert :
/proc/dev/fd.
Ah ? pas de ça chez moi.
Je voulais dire /proc/self/fd, mon clavier a fourché.
Ok, ça marche en effet ! -- Hervé
Luc Habert :
/proc/dev/fd.
Ah ? pas de ça chez moi.
Je voulais dire /proc/self/fd, mon clavier a fourché.
