Ecrire un fichier rempli de zéros

Ecrire un fichier rempli de zéros - C++ - Programmation

Marsh Posté le 08-01-2011 à 16:56:59    

Bonjour,
Je me demandais s'il existe une méthode rapide pour écrire un fichier (genre 4go) avec que des zéros dedans?
Un truc à base de seekp a l'air de me créer un fichier de la taille voulue, mais je ne sais pas s'il est garanti qu'il soit rempli de zéros ou plutot de valeurs non initialisées?
 

Code :
  1. std::fstream fichier(name.c_str(), std::ios::in | std::ios::out | std::ios::ate | std::ios::binary );
  2. fichier.seekp(loin,std::ios_base::beg);

Reply

Marsh Posté le 08-01-2011 à 16:56:59   

Reply

Marsh Posté le 08-01-2011 à 18:30:04    

Code :
  1. dd if=/dev/zero of=/tmp/tonfichier bs=4G


 
:o
 
C'est suffisamment rapide, ca écrit à 200MO / sec sur un disque dur SSD.

Reply

Marsh Posté le 08-01-2011 à 18:42:09    

xilebo a écrit :

Code :
  1. dd if=/dev/zero of=/tmp/tonfichier bs=4G


 
:o
 
C'est suffisamment rapide, ca écrit à 200MO / sec sur un disque dur SSD.


 
ouais mais en c++ et windows compliant je peux faire quoi?
 

Reply

Marsh Posté le 08-01-2011 à 18:47:13    

GrosBocdel a écrit :


 
ouais mais en c++ et windows compliant je peux faire quoi?
 


 
 
C'était un peu d'humour désolé :o
 
J'ai regardé l'aide sur la fonction seekp , rien ne dit que le fichier sera rempli de 0. Un bon moyen de savoir est que si tu fais ton seek de 4 GO et que la fonction retourne instantanément ( au close du stream bien entendu ), c'est qu'il n'y a aucune action de faite sur les données contenues dans le fichier. Dans ce cas, le fichier prend les valeurs qui étaient précédemment sur disque, c'est à dire indéterminé.
 
Le mieux est de boucler sur ton fichier et d'écrire des segments remplis de 0 ( tu peux faire ça avec un buffer de 16-32-64 MO sans problème ,il y a de grandes qu'il soit mis dans le cache du disque dur ). Dans tous les cas , pour 4 GO , ca mettra de 20 sec ( à 200MO par sec sur un SSD comme je te l'ai indiqué ) à 80 sec ( 50MO/sec sur un sata classique ).

Reply

Marsh Posté le 08-01-2011 à 18:57:41    

D'ac
J'avais essayé ce matin en écrivant des morceaux de 1k de zéros.
Je pouvais pas écouter si le disque moulinait ou quoi, mais il a bloqué vers 2Go (looooooongue pause) et repris pour finir jusqu'aux 4Go. Ca m'a paru bizarre. ET j'ai eu le temps de faire chauffer le café en attendant...

Reply

Marsh Posté le 08-01-2011 à 19:50:45    

Il existe des programmes qui peuvent créer d'énormes fichiers (je m'étais amusé à taper dans le 500Go, en gros) instantanément. Donc je suppose qu'il doit exister des méthodes pour le faire :)


---------------
"I can cry like Roger. It's just a shame I can't play like him" - Andy Murray, 2010
Reply

Marsh Posté le 08-01-2011 à 21:34:37    

Je ne sais pas ce que se passe sous Windows, mais sous Unix un seek va permettre de créer un fichier remplis de bytes à 0 et ne prenant pas de place sur le disque (donc la création d'un tel fichier est à peu près aussi rapide que celle d'un fichier vide).


---------------
The truth is rarely pure and never simple (Oscar Wilde)
Reply

Marsh Posté le 08-01-2011 à 21:37:05    

Un Programmeur a écrit :

Je ne sais pas ce que se passe sous Windows, mais sous Unix un seek va permettre de créer un fichier remplis de bytes à 0 et ne prenant pas de place sur le disque (donc la création d'un tel fichier est à peu près aussi rapide que celle d'un fichier vide).


Je pense que c'est le même délire sous Windows, à tester


---------------
"I can cry like Roger. It's just a shame I can't play like him" - Andy Murray, 2010
Reply

Marsh Posté le 08-01-2011 à 21:42:20    

Un Programmeur a écrit :

Je ne sais pas ce que se passe sous Windows, mais sous Unix un seek va permettre de créer un fichier remplis de bytes à 0 et ne prenant pas de place sur le disque (donc la création d'un tel fichier est à peu près aussi rapide que celle d'un fichier vide).


 
 
Je ferai un test, mais j'ai de sérieux doutes. Je ne vois pas comment le fichier peut contenir des 0 sans effectuer une opération sur le disque. Ou alors, tu sous entends que le fichier ne prend pas de place tant qu'on n'a pas fermé le descripteur, et à la fermeture , il flush les écritures , et ce sera long à ce moment là. Non ?

Reply

Marsh Posté le 08-01-2011 à 21:51:32    

WiiDS a écrit :

Il existe des programmes qui peuvent créer d'énormes fichiers (je m'étais amusé à taper dans le 500Go, en gros) instantanément. Donc je suppose qu'il doit exister des méthodes pour le faire :)

Des fichiers "sparse" ?
L'idée, c'est de définir la taille du fichier mais sans l'écrire totalement ni même allouer la place :
http://blogs.codes-sources.com/cyr [...] 16351.aspx


---------------
Doucement le matin, pas trop vite le soir.
Reply

Marsh Posté le 08-01-2011 à 21:51:32   

Reply

Marsh Posté le 09-01-2011 à 01:34:35    

xilebo a écrit :


Je ferai un test, mais j'ai de sérieux doutes. Je ne vois pas comment le fichier peut contenir des 0 sans effectuer une opération sur le disque. Ou alors, tu sous entends que le fichier ne prend pas de place tant qu'on n'a pas fermé le descripteur, et à la fermeture , il flush les écritures , et ce sera long à ce moment là. Non ?


 
Un open suivit d'un seek et d'un write.
 
Le seek va juster incrémenter la valeur de l'offset.
 
Lors du write on ne va allouer que les éventuels blocs d'indirections nécessaires plus les blocs du write => peu d'écriture et en plus y'a le buffer cache qui va retarder l'écriture des blocs.

Message cité 1 fois
Message édité par Anonymouse le 09-01-2011 à 01:37:20
Reply

Marsh Posté le 09-01-2011 à 10:24:54    

Anonymouse a écrit :


 
Un open suivit d'un seek et d'un write.
 
Le seek va juster incrémenter la valeur de l'offset.
 
Lors du write on ne va allouer que les éventuels blocs d'indirections nécessaires plus les blocs du write => peu d'écriture et en plus y'a le buffer cache qui va retarder l'écriture des blocs.


 
 
Effectivement, je viens d'effectuer ce petit programme de test (c'est du C par contre ) :  
 

Code :
  1. #include <stdio.h>
  2. int main()
  3. {
  4.         FILE *f = fopen ("titi.dat","wb" );
  5.         fseek(f,2000000000,SEEK_SET );
  6.         int v = 654654;
  7.         fwrite(&v,1,4,f);
  8.         fclose(f);
  9.         return 0;
  10. }


 
Effectivement le programme retourne quasiment instantanément, et le fichier contient bien des 0 ensuite (sauf à la fin ), vérification en tapant od -h titi.dat.
 
J'ai du mal à comprendre le mécanisme, si je crée le fichier en le remplissant de 0 à la main, ça met plus d'une minute.

Reply

Marsh Posté le 09-01-2011 à 10:30:45    

On n'écrit rien sur le disque: la table indiquant les secteurs utilisés pour le fichier contient pour ces zones une indication qu'aucun secteur n'est alloué.


---------------
The truth is rarely pure and never simple (Oscar Wilde)
Reply

Marsh Posté le 09-01-2011 à 10:33:51    

Un Programmeur a écrit :

On n'écrit rien sur le disque: la table indiquant les secteurs utilisés pour le fichier contient pour ces zones une indication qu'aucun secteur n'est alloué.


 
 
Ok, c'est donc une spécificité du système d'exploitation. Je ne savais pas que cela fonctionnait comme ça. Mais ça nécessite que l'OS ( le driver du système de fichier) tienne une table de secteurs à 0 en plus de la table d'adressage des fichiers. Pas sur que ce soit aussi efficace qu'un fichier réellement rempli de 0 , lorsque ce fichier vient à être morcelé de petites parties , comme par exemple un fichier torrent qu'on est en train de télécharger.
 
Merci de l'info en tout cas  :jap:

Reply

Marsh Posté le 09-01-2011 à 10:47:02    

xilebo a écrit :


 
 
Ok, c'est donc une spécificité du système d'exploitation. Je ne savais pas que cela fonctionnait comme ça. Mais ça nécessite que l'OS ( le driver du système de fichier) tienne une table de secteurs à 0 en plus de la table d'adressage des fichiers. Pas sur que ce soit aussi efficace qu'un fichier réellement rempli de 0 , lorsque ce fichier vient à être morcelé de petites parties , comme par exemple un fichier torrent qu'on est en train de télécharger.
 
Merci de l'info en tout cas  :jap:


 
1° T'entends quoi par table d'adressage des fichiers et table de secteurs?
 
2° T'entends quoi par lorsque ce fichier vient à être morcelé de petites partie?

Message cité 1 fois
Message édité par Anonymouse le 09-01-2011 à 10:47:41
Reply

Marsh Posté le 09-01-2011 à 10:58:02    

Si tu vois ton fichier comme une liste chaînée de secteurs, oui.   Si tu le vois comme un tableau de secteurs, il suffit de prévoir que qu'une entrée dans le tableau puisse être invalide.  Les unix sont dans la seconde tradition (qui permet un accès direct plus rapide).


---------------
The truth is rarely pure and never simple (Oscar Wilde)
Reply

Marsh Posté le 09-01-2011 à 11:02:41    

Anonymouse a écrit :


 
1° T'entends quoi par table d'adressage des fichiers et table de secteurs?
 
2° T'entends quoi par lorsque ce fichier vient à être morcelé de petites partie?


 
 
Pour accéder à un fichier, il faut bien une table qui indique à quel secteur se positionner. C'est ce qu'on appelle la FAT ou la table d'inode par exemple selon le système de fichier utilisé. Je sais qu'un fichier peut ne pas être contigu, et dans ce cas, selon la méthode d'adressage, l'OS ( le driver ) tient une table de tout ce qui peut composer le fichier. Maintenant, je ne savais pas qu'en plus ( mais ça parait logique en y réfléchissant) qu'il est capable de prendre en compte des secteurs remplis de 0 sans qu'ils le soient réellement (c'est bien ce qui a été dit non ? ). Dans ce cas, il y a bien quelque chose qui indique que tel bloc de secteur est un bloc composé de 0, ça peut être un flag par exemple.  
 
Ce qui signifie, si je ne me trompe pas, pour un fichier créé de cette façon, qu'il ne sera pas représenté dans sa table d'adressage , de la même manière qu'un fichier remplis réellement de 0, ce qui implique donc une différence de performance. Après, elle est peut-être insignifiante.
 
 
Pour le point 2, j'ai pris un exemple d'application qui écrit dans le fichier de façon aléatoire (selon ce qu'il a reçu ), la table d'adressage du fichier va constamment être mise à jour, j'ai l'impression que ce n'est pas une bonne chose.
 
 
edit :  
 

Un Programmeur a écrit :

Si tu vois ton fichier comme une liste chaînée de secteurs, oui.   Si tu le vois comme un tableau de secteurs, il suffit de prévoir que qu'une entrée dans le tableau puisse être invalide.  Les unix sont dans la seconde tradition (qui permet un accès direct plus rapide).


 
 
Ok, je comprends mieux  :jap:

Message cité 1 fois
Message édité par xilebo le 09-01-2011 à 11:03:36
Reply

Marsh Posté le 09-01-2011 à 11:14:03    

xilebo a écrit :


 
 
Pour accéder à un fichier, il faut bien une table qui indique à quel secteur se positionner. C'est ce qu'on appelle la FAT ou la table d'inode par exemple selon le système de fichier utilisé. Je sais qu'un fichier peut ne pas être contigu, et dans ce cas, selon la méthode d'adressage, l'OS ( le driver ) tient une table de tout ce qui peut composer le fichier. Maintenant, je ne savais pas qu'en plus ( mais ça parait logique en y réfléchissant) qu'il est capable de prendre en compte des secteurs remplis de 0 sans qu'ils le soient réellement (c'est bien ce qui a été dit non ? ). Dans ce cas, il y a bien quelque chose qui indique que tel bloc de secteur est un bloc composé de 0, ça peut être un flag par exemple.  
 
Ce qui signifie, si je ne me trompe pas, pour un fichier créé de cette façon, qu'il ne sera pas représenté dans sa table d'adressage , de la même manière qu'un fichier remplis réellement de 0, ce qui implique donc une différence de performance. Après, elle est peut-être insignifiante.
 
Dans l'inode il y'a une table (tableau) des blocs utilisés : les X 1er cases comportent l'adresse des X 1er bloc. Les 3 dernieres contiennent les blocs d'indirection. La différence entre un fichier entièrement composé de 0 et l'autre type de fichuier c'est que dans le 1er cas les entrées de la table poitent vers des blocs qui contiennent des 0 et dans le 2e cas pointent sur NULL.
 
Pour le point 2, j'ai pris un exemple d'application qui écrit dans le fichier de façon aléatoire (selon ce qu'il a reçu ), la table d'adressage du fichier va constamment être mise à jour, j'ai l'impression que ce n'est pas une bonne chose.
 
Ca change rien : le système va être obligé de faire des E/S et le buffer cache ne va pas être d'une grande utilité dans tous les cas.
 
edit :  
 


Message édité par Anonymouse le 09-01-2011 à 11:16:42
Reply

Marsh Posté le 09-01-2011 à 12:02:22    

Merci pour toutes ces précisions  :jap:  En espérant que ça serve également à l'auteur du topic !

Reply

Marsh Posté le 09-01-2011 à 12:14:22    

xilebo a écrit :

Merci pour toutes ces précisions  :jap:  En espérant que ça serve également à l'auteur du topic !


ouep, je lis, je lis.
Donc si j'ai bien compris, oui j'ai bien mon fichier rempli de "zéros" mais le temps gagné en faisant ça sera perdu quand j'écrirai mes vraies données dans le fichier

Reply

Marsh Posté le 09-01-2011 à 15:35:03    

La principale utilité est le gain d'espace disque (les 0 ne sont pas écrits et si c'est pour un fichier indexé, il peut y avoir des zones où on n'écrira jamais), mais si tu ne gagnes rien par rapport à écrire directement la valeur finale, tu gagnes quand même par rapport à écrire des 0 puis la valeur finale.


---------------
The truth is rarely pure and never simple (Oscar Wilde)
Reply

Marsh Posté le 09-01-2011 à 15:48:26    

Un Programmeur a écrit :

La principale utilité est le gain d'espace disque (les 0 ne sont pas écrits et si c'est pour un fichier indexé, il peut y avoir des zones où on n'écrira jamais), mais si tu ne gagnes rien par rapport à écrire directement la valeur finale, tu gagnes quand même par rapport à écrire des 0 puis la valeur finale.


 
C'est cool c'est ce que veux. Je sais que j'écrirai dans tout le fichier, mais je ne sais pas dans quel ordre. Ca donc ça me permet de me réserver l'espace pour la suite.  :jap:  
 
Et puis bon, on peut maintenant revenir aux disquettes puisqu'on sait qu'on peut stocker une quantité illimitée d'informations dans un espace nul  :D  

Reply

Marsh Posté le 09-01-2011 à 15:49:14    

xilebo a écrit :

Ok, c'est donc une spécificité du système d'exploitation.

Je ne sais pas quel FS a implémenté ça le premier, mais la première fois que je l'ai vu, c'est il y a bien longtemps, sous SUN OS et son FS de l'époque. L'équivalent sous NTFS est arrivé plus tard.
A+,


---------------
There's more than what can be linked! --    Iyashikei Anime Forever!    --  AngularJS c'est un framework d'engulé!  --
Reply

Marsh Posté le 09-01-2011 à 17:19:56    

gilou a écrit :

Je ne sais pas quel FS a implémenté ça le premier, mais la première fois que je l'ai vu, c'est il y a bien longtemps, sous SUN OS et son FS de l'époque. L'équivalent sous NTFS est arrivé plus tard.
A+,


 
C'est au moins possible depuis Unix V7.


---------------
The truth is rarely pure and never simple (Oscar Wilde)
Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed