Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Remi Moyen
On Thu, 29 Apr 2004, deepthroat wrote:
Bonjour, j'ai beau chercher, je ne trouve pas d'application pour generer un fichier (contenu aleatoire) d'une taille precise, cela existe-t'il ?
Un truc genre :
dd if=/dev/random of=/tmp/blurp bs=1M count
(avec /dev/random, urandom, zero, ... suivant le résultat cherché) (et bs=1M doit être une option gnu, mais sinon, yaka mettre bs24k)
Au passage, y'aurait-il un intérêt particulier à faire, par exemple, bs=1k count24 plutôt que bs24k count=1 (ou le contraire) ? -- Rémi Moyen "Malgré les apparences, le temps est très varié à Nancy : pluie, nuages, neige, brouillard, grêle, ..."
On Thu, 29 Apr 2004, deepthroat wrote:
Bonjour, j'ai beau chercher, je ne trouve pas d'application pour generer
un fichier (contenu aleatoire) d'une taille precise, cela existe-t'il ?
Un truc genre :
dd if=/dev/random of=/tmp/blurp bs=1M count
(avec /dev/random, urandom, zero, ... suivant le résultat cherché)
(et bs=1M doit être une option gnu, mais sinon, yaka mettre bs24k)
Au passage, y'aurait-il un intérêt particulier à faire, par exemple, bs=1k
count24 plutôt que bs24k count=1 (ou le contraire) ?
--
Rémi Moyen
"Malgré les apparences, le temps est très varié à Nancy :
pluie, nuages, neige, brouillard, grêle, ..."
Bonjour, j'ai beau chercher, je ne trouve pas d'application pour generer un fichier (contenu aleatoire) d'une taille precise, cela existe-t'il ?
Un truc genre :
dd if=/dev/random of=/tmp/blurp bs=1M count
(avec /dev/random, urandom, zero, ... suivant le résultat cherché) (et bs=1M doit être une option gnu, mais sinon, yaka mettre bs24k)
Au passage, y'aurait-il un intérêt particulier à faire, par exemple, bs=1k count24 plutôt que bs24k count=1 (ou le contraire) ? -- Rémi Moyen "Malgré les apparences, le temps est très varié à Nancy : pluie, nuages, neige, brouillard, grêle, ..."
JustMe
deepthroat wrote:
Bonjour, j'ai beau chercher, je ne trouve pas d'application pour generer un fichier (contenu aleatoire) d'une taille precise, cela existe-t'il ?
dd if=/dev/random of=fichier bs24k count=1 => 1 mo dd if=/dev/random of=fichier bs24k count => 10 mo
etc...
si tu as /dev/random
deepthroat wrote:
Bonjour, j'ai beau chercher, je ne trouve pas d'application pour generer
un fichier (contenu aleatoire) d'une taille precise, cela existe-t'il ?
dd if=/dev/random of=fichier bs24k count=1 => 1 mo
dd if=/dev/random of=fichier bs24k count => 10 mo
Bonjour, j'ai beau chercher, je ne trouve pas d'application pour generer un fichier (contenu aleatoire) d'une taille precise, cela existe-t'il ?
Un truc genre :
dd if=/dev/random of=/tmp/blurp bs=1M count
(avec /dev/random, urandom, zero, ... suivant le résultat cherché) (et bs=1M doit être une option gnu, mais sinon, yaka mettre bs24k)
Au passage, y'aurait-il un intérêt particulier à faire, par exemple, bs=1k count24 plutôt que bs24k count=1 (ou le contraire) ? oui
car dans 1 cas tu met en memoir 1 Mo et ensuite tu ecrit dans l autre cas tu met en memoire 1 k et tu ecrit et tu repoete 1024 fois cela.
il y a plus de contexte a faire la seconde memthode.
essaye de faire la differnce de temps entre
dd if=/dev/zero of=/tmp/toto bs=1 count48576
et
dd if=/dev/zero of=/tmp/toto bs48576 count=1
ca sera pas la meme chose.
kilobug
On Thu, 29 Apr 2004, deepthroat wrote:
Bonjour, j'ai beau chercher, je ne trouve pas d'application pour generer un fichier (contenu aleatoire) d'une taille precise, cela existe-t'il ?
Un truc genre :
dd if=/dev/random of=/tmp/blurp bs=1M count
(avec /dev/random, urandom, zero, ... suivant le résultat cherché) (et bs=1M doit être une option gnu, mais sinon, yaka mettre bs24k)
/dev/urandom plutôt, sinon ça va prendre un temps fou. /dev/random donne de l'entropie "forte" (liée au matériel, ...) et ne donne donc que quelques octets par seconde. /dev/urandom complète cette entropie forte avec du PRNG et donne donc des données aussi vite que nécessaire, ou presque.
Au passage, y'aurait-il un intérêt particulier à faire, par exemple, bs=1k count24 plutôt que bs24k count=1 (ou le contraire) ?
Dans ce cas là, pas vraiment... si ce n'est qu'il vaut mieux avoir une taille de bloc (bs) qui soit un multiple de la taille du bloc sur le disque (4k par défaut) pour des raisons de performance.
-- Gael Le Mignot "Kilobug" - - http://kilobug.free.fr GSM : 06.71.47.18.22 (in France) ICQ UIN : 7299959 Fingerprint : 1F2C 9804 7505 79DF 95E6 7323 B66B F67B 7103 C5DA
Member of HurdFr: http://hurdfr.org - The GNU Hurd: http://hurd.gnu.org
On Thu, 29 Apr 2004, deepthroat wrote:
Bonjour, j'ai beau chercher, je ne trouve pas d'application pour generer
un fichier (contenu aleatoire) d'une taille precise, cela existe-t'il ?
Un truc genre :
dd if=/dev/random of=/tmp/blurp bs=1M count
(avec /dev/random, urandom, zero, ... suivant le résultat cherché)
(et bs=1M doit être une option gnu, mais sinon, yaka mettre bs24k)
/dev/urandom plutôt, sinon ça va prendre un temps fou. /dev/random
donne de l'entropie "forte" (liée au matériel, ...) et ne donne donc
que quelques octets par seconde. /dev/urandom complète cette entropie
forte avec du PRNG et donne donc des données aussi vite que
nécessaire, ou presque.
Au passage, y'aurait-il un intérêt particulier à faire, par exemple, bs=1k
count24 plutôt que bs24k count=1 (ou le contraire) ?
Dans ce cas là, pas vraiment... si ce n'est qu'il vaut mieux avoir une
taille de bloc (bs) qui soit un multiple de la taille du bloc sur le
disque (4k par défaut) pour des raisons de performance.
--
Gael Le Mignot "Kilobug" - kilobug@nerim.net - http://kilobug.free.fr
GSM : 06.71.47.18.22 (in France) ICQ UIN : 7299959
Fingerprint : 1F2C 9804 7505 79DF 95E6 7323 B66B F67B 7103 C5DA
Member of HurdFr: http://hurdfr.org - The GNU Hurd: http://hurd.gnu.org
Bonjour, j'ai beau chercher, je ne trouve pas d'application pour generer un fichier (contenu aleatoire) d'une taille precise, cela existe-t'il ?
Un truc genre :
dd if=/dev/random of=/tmp/blurp bs=1M count
(avec /dev/random, urandom, zero, ... suivant le résultat cherché) (et bs=1M doit être une option gnu, mais sinon, yaka mettre bs24k)
/dev/urandom plutôt, sinon ça va prendre un temps fou. /dev/random donne de l'entropie "forte" (liée au matériel, ...) et ne donne donc que quelques octets par seconde. /dev/urandom complète cette entropie forte avec du PRNG et donne donc des données aussi vite que nécessaire, ou presque.
Au passage, y'aurait-il un intérêt particulier à faire, par exemple, bs=1k count24 plutôt que bs24k count=1 (ou le contraire) ?
Dans ce cas là, pas vraiment... si ce n'est qu'il vaut mieux avoir une taille de bloc (bs) qui soit un multiple de la taille du bloc sur le disque (4k par défaut) pour des raisons de performance.
-- Gael Le Mignot "Kilobug" - - http://kilobug.free.fr GSM : 06.71.47.18.22 (in France) ICQ UIN : 7299959 Fingerprint : 1F2C 9804 7505 79DF 95E6 7323 B66B F67B 7103 C5DA
Member of HurdFr: http://hurdfr.org - The GNU Hurd: http://hurd.gnu.org
kilobug
On Thu, 29 Apr 2004 15:24:29 +0200 "[Sauron De Mordor]" wrote:
@@
Au passage, y'aurait-il un intérêt particulier à faire, par exemple, bs=1k count24 plutôt que bs24k count=1 (ou le contraire) ? oui
car dans 1 cas tu met en memoir 1 Mo et ensuite tu ecrit dans l autre cas tu met en memoire 1 k et tu ecrit et tu repoete 1024 fois cela.
il y a plus de contexte a faire la seconde methode.
au vu des resultats que j'ai, il n'y aurait pas aussi un probleme d'entree/sortie ?
essaye de faire la differnce de temps entre ... @@
ca sera pas la meme chose.
effectivement, ce n'est pas du tout pareil ^_^
$ time dd if=/dev/zero of=/tmp/toto bs48576 count=1 0s real 0.010s user 0.050s system
$ time dd if=/dev/zero of=/tmp/toto bs=1 count48576 91s real 9.820s user 79.860s system 97%
Comme je le disais, c'est surtout en comparaison à la taille d'un bloc disque que cela joue:
4096 blocs de 4095 octets contre 4095 blocs de 4096 octets:
dd if=/dev/zero of=plop 4095+0 records in 4095+0 records out 16773120 bytes transferred in 0.155924 seconds (107572472 bytes/sec)
dd if=/dev/zero of=plop 4096+0 records in 4096+0 records out 16773120 bytes transferred in 0.186825 seconds (89779850 bytes/sec)
4097 blocs de 4096 octets contre 4096 blocs de 4097 octets:
dd if=/dev/zero of=plop 4097+0 records in 4097+0 records out 16781312 bytes transferred in 0.155621 seconds (107834501 bytes/sec)
dd if=/dev/zero of=plop 4096+0 records in 4096+0 records out 16781312 bytes transferred in 0.181511 seconds (92453422 bytes/sec)
Ce n'est pas tant la taille exacte du bloc qui joue mais son rapport avec la taille du bloc disque. Quand c'est la même taille (4096) ou un multiple (8192, ...) on a des performances optimales, quand le bs n'est pas un multiple de la taille du bloc disque, on perd.
Maintenant, la taille du bloc joue aussi:
dd if=/dev/zero of=plop 4096+0 records in 4096+0 records out 16777216 bytes transferred in 0.162895 seconds (102993998 bytes/sec)
dd if=/dev/zero of=plop bs92 count 48 2048+0 records in 2048+0 records out 16777216 bytes transferred in 0.154770 seconds (108400913 bytes/sec)
dd if=/dev/zero of=plop bs384 count24 1024+0 records in 1024+0 records out 16777216 bytes transferred in 0.140720 seconds (119224013 bytes/sec)
-- Gael Le Mignot "Kilobug" - - http://kilobug.free.fr GSM : 06.71.47.18.22 (in France) ICQ UIN : 7299959 Fingerprint : 1F2C 9804 7505 79DF 95E6 7323 B66B F67B 7103 C5DA
Member of HurdFr: http://hurdfr.org - The GNU Hurd: http://hurd.gnu.org
On Thu, 29 Apr 2004 15:24:29 +0200
"[Sauron De Mordor]" <ici_ou_ailleur@autrepart.com> wrote:
@@
Au passage, y'aurait-il un intérêt particulier à faire, par exemple,
bs=1k count24 plutôt que bs24k count=1 (ou le contraire) ?
oui
car dans 1 cas tu met en memoir 1 Mo et ensuite tu ecrit dans l autre
cas tu met en memoire 1 k et tu ecrit et tu repoete 1024 fois cela.
il y a plus de contexte a faire la seconde methode.
au vu des resultats que j'ai, il n'y aurait pas aussi
un probleme d'entree/sortie ?
essaye de faire la differnce de temps entre ...
@@
ca sera pas la meme chose.
effectivement, ce n'est pas du tout pareil ^_^
$ time dd if=/dev/zero of=/tmp/toto bs48576 count=1
0s real 0.010s user 0.050s system
$ time dd if=/dev/zero of=/tmp/toto bs=1 count48576
91s real 9.820s user 79.860s system 97%
Comme je le disais, c'est surtout en comparaison à la taille d'un bloc disque
que cela joue:
4096 blocs de 4095 octets contre 4095 blocs de 4096 octets:
dd if=/dev/zero of=plop bs@96 count@95
4095+0 records in
4095+0 records out
16773120 bytes transferred in 0.155924 seconds (107572472 bytes/sec)
dd if=/dev/zero of=plop bs@95 count@96
4096+0 records in
4096+0 records out
16773120 bytes transferred in 0.186825 seconds (89779850 bytes/sec)
4097 blocs de 4096 octets contre 4096 blocs de 4097 octets:
dd if=/dev/zero of=plop bs@96 count@97
4097+0 records in
4097+0 records out
16781312 bytes transferred in 0.155621 seconds (107834501 bytes/sec)
dd if=/dev/zero of=plop bs@97 count@96
4096+0 records in
4096+0 records out
16781312 bytes transferred in 0.181511 seconds (92453422 bytes/sec)
Ce n'est pas tant la taille exacte du bloc qui joue mais son rapport
avec la taille du bloc disque. Quand c'est la même taille (4096) ou un
multiple (8192, ...) on a des performances optimales, quand le bs
n'est pas un multiple de la taille du bloc disque, on perd.
Maintenant, la taille du bloc joue aussi:
dd if=/dev/zero of=plop bs@96 count@96
4096+0 records in
4096+0 records out
16777216 bytes transferred in 0.162895 seconds (102993998 bytes/sec)
dd if=/dev/zero of=plop bs92 count 48
2048+0 records in
2048+0 records out
16777216 bytes transferred in 0.154770 seconds (108400913 bytes/sec)
dd if=/dev/zero of=plop bs384 count24
1024+0 records in
1024+0 records out
16777216 bytes transferred in 0.140720 seconds (119224013 bytes/sec)
--
Gael Le Mignot "Kilobug" - kilobug@nerim.net - http://kilobug.free.fr
GSM : 06.71.47.18.22 (in France) ICQ UIN : 7299959
Fingerprint : 1F2C 9804 7505 79DF 95E6 7323 B66B F67B 7103 C5DA
Member of HurdFr: http://hurdfr.org - The GNU Hurd: http://hurd.gnu.org
On Thu, 29 Apr 2004 15:24:29 +0200 "[Sauron De Mordor]" wrote:
@@
Au passage, y'aurait-il un intérêt particulier à faire, par exemple, bs=1k count24 plutôt que bs24k count=1 (ou le contraire) ? oui
car dans 1 cas tu met en memoir 1 Mo et ensuite tu ecrit dans l autre cas tu met en memoire 1 k et tu ecrit et tu repoete 1024 fois cela.
il y a plus de contexte a faire la seconde methode.
au vu des resultats que j'ai, il n'y aurait pas aussi un probleme d'entree/sortie ?
essaye de faire la differnce de temps entre ... @@
ca sera pas la meme chose.
effectivement, ce n'est pas du tout pareil ^_^
$ time dd if=/dev/zero of=/tmp/toto bs48576 count=1 0s real 0.010s user 0.050s system
$ time dd if=/dev/zero of=/tmp/toto bs=1 count48576 91s real 9.820s user 79.860s system 97%
Comme je le disais, c'est surtout en comparaison à la taille d'un bloc disque que cela joue:
4096 blocs de 4095 octets contre 4095 blocs de 4096 octets:
dd if=/dev/zero of=plop 4095+0 records in 4095+0 records out 16773120 bytes transferred in 0.155924 seconds (107572472 bytes/sec)
dd if=/dev/zero of=plop 4096+0 records in 4096+0 records out 16773120 bytes transferred in 0.186825 seconds (89779850 bytes/sec)
4097 blocs de 4096 octets contre 4096 blocs de 4097 octets:
dd if=/dev/zero of=plop 4097+0 records in 4097+0 records out 16781312 bytes transferred in 0.155621 seconds (107834501 bytes/sec)
dd if=/dev/zero of=plop 4096+0 records in 4096+0 records out 16781312 bytes transferred in 0.181511 seconds (92453422 bytes/sec)
Ce n'est pas tant la taille exacte du bloc qui joue mais son rapport avec la taille du bloc disque. Quand c'est la même taille (4096) ou un multiple (8192, ...) on a des performances optimales, quand le bs n'est pas un multiple de la taille du bloc disque, on perd.
Maintenant, la taille du bloc joue aussi:
dd if=/dev/zero of=plop 4096+0 records in 4096+0 records out 16777216 bytes transferred in 0.162895 seconds (102993998 bytes/sec)
dd if=/dev/zero of=plop bs92 count 48 2048+0 records in 2048+0 records out 16777216 bytes transferred in 0.154770 seconds (108400913 bytes/sec)
dd if=/dev/zero of=plop bs384 count24 1024+0 records in 1024+0 records out 16777216 bytes transferred in 0.140720 seconds (119224013 bytes/sec)
-- Gael Le Mignot "Kilobug" - - http://kilobug.free.fr GSM : 06.71.47.18.22 (in France) ICQ UIN : 7299959 Fingerprint : 1F2C 9804 7505 79DF 95E6 7323 B66B F67B 7103 C5DA
Member of HurdFr: http://hurdfr.org - The GNU Hurd: http://hurd.gnu.org
DESILE Matthieu
On Thu, 29 Apr 2004 15:24:29 +0200 "[Sauron De Mordor]" wrote:
@@
Au passage, y'aurait-il un intérêt particulier à faire, par exemp le, bs=1k count24 plutôt que bs24k count=1 (ou le contraire ) ? oui
car dans 1 cas tu met en memoir 1 Mo et ensuite tu ecrit dans l autre cas tu met en memoire 1 k et tu ecrit et tu repoete 1024 fois cela.
il y a plus de contexte a faire la seconde methode.
au vu des resultats que j'ai, il n'y aurait pas aussi un probleme d'entree/sortie ?
essaye de faire la differnce de temps entre ... @@
ca sera pas la meme chose.
effectivement, ce n'est pas du tout pareil ^_^
$ time dd if=/dev/zero of=/tmp/toto bs48576 count=1 0s real 0.010s user 0.050s system
$ time dd if=/dev/zero of=/tmp/toto bs=1 count48576 91s real 9.820s user 79.860s system 97%
-- Matthieu
On Thu, 29 Apr 2004 15:24:29 +0200
"[Sauron De Mordor]" <ici_ou_ailleur@autrepart.com> wrote:
@@
Au passage, y'aurait-il un intérêt particulier à faire, par exemp le,
bs=1k count=1024 plutôt que bs=1024k count=1 (ou le contraire ) ?
oui
car dans 1 cas tu met en memoir 1 Mo et ensuite tu ecrit dans l autre
cas tu met en memoire 1 k et tu ecrit et tu repoete 1024 fois cela.
il y a plus de contexte a faire la seconde methode.
au vu des resultats que j'ai, il n'y aurait pas aussi
un probleme d'entree/sortie ?
essaye de faire la differnce de temps entre ...
@@
ca sera pas la meme chose.
effectivement, ce n'est pas du tout pareil ^_^
$ time dd if=/dev/zero of=/tmp/toto bs=1048576 count=1
0s real 0.010s user 0.050s system
$ time dd if=/dev/zero of=/tmp/toto bs=1 count=1048576
91s real 9.820s user 79.860s system 97%
On Thu, 29 Apr 2004 15:24:29 +0200 "[Sauron De Mordor]" wrote:
@@
Au passage, y'aurait-il un intérêt particulier à faire, par exemp le, bs=1k count24 plutôt que bs24k count=1 (ou le contraire ) ? oui
car dans 1 cas tu met en memoir 1 Mo et ensuite tu ecrit dans l autre cas tu met en memoire 1 k et tu ecrit et tu repoete 1024 fois cela.
il y a plus de contexte a faire la seconde methode.
au vu des resultats que j'ai, il n'y aurait pas aussi un probleme d'entree/sortie ?
essaye de faire la differnce de temps entre ... @@
ca sera pas la meme chose.
effectivement, ce n'est pas du tout pareil ^_^
$ time dd if=/dev/zero of=/tmp/toto bs48576 count=1 0s real 0.010s user 0.050s system
$ time dd if=/dev/zero of=/tmp/toto bs=1 count48576 91s real 9.820s user 79.860s system 97%
-- Matthieu
Remi Moyen
On Thu, 29 Apr 2004, Gaël Le Mignot wrote:
Comme je le disais, c'est surtout en comparaison à la taille d'un bloc disque que cela joue:
4096 blocs de 4095 octets contre 4095 blocs de 4096 octets: [...]
4097 blocs de 4096 octets contre 4096 blocs de 4097 octets: [...]
Ok, dans ces cas-là, je comprends bien pourquoi c'est plus ou moins rapide.
Maintenant, la taille du bloc joue aussi:
Ça, par contre, je ne comprends pas pourquoi. C'est parce qu'un accès disque différent est fait pour chaque bloc écrit ? Je sens que Sauron a donné la réponse, mais j'avoue que je n'ai pas du tout compris son message... -- Rémi Moyen "Malgré les apparences, le temps est très varié à Nancy : pluie, nuages, neige, brouillard, grêle, ..."
On Thu, 29 Apr 2004, Gaël Le Mignot wrote:
Comme je le disais, c'est surtout en comparaison à la taille d'un bloc disque
que cela joue:
4096 blocs de 4095 octets contre 4095 blocs de 4096 octets:
[...]
4097 blocs de 4096 octets contre 4096 blocs de 4097 octets:
[...]
Ok, dans ces cas-là, je comprends bien pourquoi c'est plus ou moins
rapide.
Maintenant, la taille du bloc joue aussi:
Ça, par contre, je ne comprends pas pourquoi. C'est parce qu'un accès
disque différent est fait pour chaque bloc écrit ? Je sens que Sauron a
donné la réponse, mais j'avoue que je n'ai pas du tout compris son
message...
--
Rémi Moyen
"Malgré les apparences, le temps est très varié à Nancy :
pluie, nuages, neige, brouillard, grêle, ..."
Comme je le disais, c'est surtout en comparaison à la taille d'un bloc disque que cela joue:
4096 blocs de 4095 octets contre 4095 blocs de 4096 octets: [...]
4097 blocs de 4096 octets contre 4096 blocs de 4097 octets: [...]
Ok, dans ces cas-là, je comprends bien pourquoi c'est plus ou moins rapide.
Maintenant, la taille du bloc joue aussi:
Ça, par contre, je ne comprends pas pourquoi. C'est parce qu'un accès disque différent est fait pour chaque bloc écrit ? Je sens que Sauron a donné la réponse, mais j'avoue que je n'ai pas du tout compris son message... -- Rémi Moyen "Malgré les apparences, le temps est très varié à Nancy : pluie, nuages, neige, brouillard, grêle, ..."
Swaz
deepthroat tint à peu près ce langage :
Bonjour, j'ai beau chercher, je ne trouve pas d'application pour generer un fichier (contenu aleatoire) d'une taille precise, cela existe-t'il ?
Bonjour,
Il y a /usr/sbin/mkfile sous Solaris :
mkfile 1m /tmp/un_mega mkfile 1g /tmp/un_giga
Swaz.
deepthroat tint à peu près ce langage :
Bonjour, j'ai beau chercher, je ne trouve pas d'application pour
generer un fichier (contenu aleatoire) d'une taille precise, cela
existe-t'il ?
Bonjour, j'ai beau chercher, je ne trouve pas d'application pour generer un fichier (contenu aleatoire) d'une taille precise, cela existe-t'il ?
Bonjour,
Il y a /usr/sbin/mkfile sous Solaris :
mkfile 1m /tmp/un_mega mkfile 1g /tmp/un_giga
Swaz.
kilobug
Maintenant, la taille du bloc joue aussi:
Ça, par contre, je ne comprends pas pourquoi. C'est parce qu'un accès disque différent est fait pour chaque bloc écrit ? Je sens que Sauron a donné la réponse, mais j'avoue que je n'ai pas du tout compris son message...
Hum, je ne sais pas trop d'où ça vient... je vois plusieurs causes possibles mais aucune ne me satisifait vraiment. Y'a les appels systèmes qui prennent du temps (passer en mode noyau, repasser en mode utilisateur) et il en fait moins quand il travaille sur des gros blocs. Il y a aussi les transactions vis à vis du disque (j'utilise ext3fs, donc il doit écrire dans le journal pour chaque transaction, ça peut jouer un peu). Il y aussi l'attente pour que les têtes du disques soient à la bonne place, normalement, si les données à lire ou écrire sont continues (pas de fragmentation) il peut les lire ou écrire dans la foulée pendant la rotation du plateau, si l'accès est fait en plusieurs fois, il est obligé d'attendre que la rotation amène le disque au bon endroit à chaque fois.
Mais je ne sais pas quelle cause joue vraiment... ou si c'est un peu de tout... ou encore si autre chose de complètement différent.
-- Gael Le Mignot "Kilobug" - - http://kilobug.free.fr GSM : 06.71.47.18.22 (in France) ICQ UIN : 7299959 Fingerprint : 1F2C 9804 7505 79DF 95E6 7323 B66B F67B 7103 C5DA
Member of HurdFr: http://hurdfr.org - The GNU Hurd: http://hurd.gnu.org
Maintenant, la taille du bloc joue aussi:
Ça, par contre, je ne comprends pas pourquoi. C'est parce qu'un accès
disque différent est fait pour chaque bloc écrit ? Je sens que Sauron a
donné la réponse, mais j'avoue que je n'ai pas du tout compris son
message...
Hum, je ne sais pas trop d'où ça vient... je vois plusieurs causes
possibles mais aucune ne me satisifait vraiment. Y'a les appels
systèmes qui prennent du temps (passer en mode noyau, repasser en mode
utilisateur) et il en fait moins quand il travaille sur des gros
blocs. Il y a aussi les transactions vis à vis du disque (j'utilise
ext3fs, donc il doit écrire dans le journal pour chaque transaction,
ça peut jouer un peu). Il y aussi l'attente pour que les têtes du
disques soient à la bonne place, normalement, si les données à lire ou
écrire sont continues (pas de fragmentation) il peut les lire ou
écrire dans la foulée pendant la rotation du plateau, si l'accès est
fait en plusieurs fois, il est obligé d'attendre que la rotation amène
le disque au bon endroit à chaque fois.
Mais je ne sais pas quelle cause joue vraiment... ou si c'est un peu
de tout... ou encore si autre chose de complètement différent.
--
Gael Le Mignot "Kilobug" - kilobug@nerim.net - http://kilobug.free.fr
GSM : 06.71.47.18.22 (in France) ICQ UIN : 7299959
Fingerprint : 1F2C 9804 7505 79DF 95E6 7323 B66B F67B 7103 C5DA
Member of HurdFr: http://hurdfr.org - The GNU Hurd: http://hurd.gnu.org
Ça, par contre, je ne comprends pas pourquoi. C'est parce qu'un accès disque différent est fait pour chaque bloc écrit ? Je sens que Sauron a donné la réponse, mais j'avoue que je n'ai pas du tout compris son message...
Hum, je ne sais pas trop d'où ça vient... je vois plusieurs causes possibles mais aucune ne me satisifait vraiment. Y'a les appels systèmes qui prennent du temps (passer en mode noyau, repasser en mode utilisateur) et il en fait moins quand il travaille sur des gros blocs. Il y a aussi les transactions vis à vis du disque (j'utilise ext3fs, donc il doit écrire dans le journal pour chaque transaction, ça peut jouer un peu). Il y aussi l'attente pour que les têtes du disques soient à la bonne place, normalement, si les données à lire ou écrire sont continues (pas de fragmentation) il peut les lire ou écrire dans la foulée pendant la rotation du plateau, si l'accès est fait en plusieurs fois, il est obligé d'attendre que la rotation amène le disque au bon endroit à chaque fois.
Mais je ne sais pas quelle cause joue vraiment... ou si c'est un peu de tout... ou encore si autre chose de complètement différent.
-- Gael Le Mignot "Kilobug" - - http://kilobug.free.fr GSM : 06.71.47.18.22 (in France) ICQ UIN : 7299959 Fingerprint : 1F2C 9804 7505 79DF 95E6 7323 B66B F67B 7103 C5DA
Member of HurdFr: http://hurdfr.org - The GNU Hurd: http://hurd.gnu.org
