Generer un fichier de 1Mo, 10Mo, 100Mo, 1Go

Le
deepthroat
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 ?
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Remi Moyen
Le #457108
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, ..."

JustMe
Le #457107
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

Erwan David
Le #457106
deepthroat
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 en choisissant bien bs et count, avec /dev/urandom ou /dev/zero
comme entrée.


--
Real programs don't eat cache

[Sauron De Mordor]
Le #457105
Remi Moyen wrote:

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) ?
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
Le #457104

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


kilobug
Le #457103

On Thu, 29 Apr 2004 15:24:29 +0200
"[Sauron De Mordor]"

@@
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 bs92 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
Le #457102
On Thu, 29 Apr 2004 15:24:29 +0200
"[Sauron De Mordor]"
@@
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
Le #456930
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, ..."

Swaz
Le #456929
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.

kilobug
Le #456928

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


Publicité
Poster une réponse
Anonyme