Différence entre taille réelle et taille sur le disque

Différence entre taille réelle et taille sur le disque - Disque dur - Hardware

Marsh Posté le 19-08-2003 à 09:19:06    

Bonjour,
 
Je réalise actuellement une application qui télécharge des données et les stocke dans des fichiers et des répertoires...
 
Actuellement, je n'ai que :
 
   - un seul fichier par répertoire
   - 3533 répertoires
   - chaque fichier pèse entre 50 et 80 octets.
 
Lorsque j'ai fait mon petit calcul à la main (3533*80) j'ai obtenu que mes fichiers devraient peser au total 282 ko.
 
Cependant... Lorsque, sous DOS, je fais un dir/s... j'obtiens une taille d'environ 8 Mo...
 
Et sous Windows 2000, en affichant les propriétés du répertoire j'obtiens :
     Taille : 216 ko
     Taille sur le disque : 13,8 Mo
 
 
Avez-vous une idée d'où viennent toutes ces différences ?? Est-ce que, lorsque chacun de mes fichiers des répertoires seront un peu plus gros, le ratio taille sur le disque / taille prévue sera plus faible ??
 
Encore une dernière question... Sachant que ces 3533 répertoires correspondent à 3533 stations de mesures, et qu'1 fichier correspond aux mesures d'1 mois (1 fichier pésera entre 500 ko et 1 Mo) vaut-il mieux que je poursuive comme j'ai commencé à présent (1 répertoire pour chaque station, puis 1 fichier par mois) ou que j'organise différemment mes données pour minimiser leur accès sur le disque tout en garantissant un accès rapide aux données ??
 
Merci par avance pour toutes vos réponses !!!


Message édité par benj63 le 19-08-2003 à 13:18:22
Reply

Marsh Posté le 19-08-2003 à 09:19:06   

Reply

Marsh Posté le 19-08-2003 à 09:22:55    

fait un  

chkdsk


 
le "Octets dans chaque untité d'allocation", c'est la taille minimale d'un fichier, donc ça sera toujours multiples de ce nombres.


---------------
CPU-Z | Timespy | Mes bd
Reply

Marsh Posté le 19-08-2003 à 09:28:24    

Ca dépend de la taille des clusters sur le disque.
Si elle est de 8ko par exemple, un fichier de 1 octet (pas possible mais bon) prendra 8Ko sur le disque. Et un fichier de 8193 octets (soit 8ko + 1) prendra 16Ko (2 clusters).
 
Tes 3533 folders prennent donc déjà 28Mo au minimum (avec une taille cluster de 8Ko).
 
A mon avis, tes clusters doivent être de 4Ko car 3533x4/1024 = 13.8Mo , chaque folder même vide prenant 4Ko.


Message édité par Deadlock le 19-08-2003 à 09:29:19

---------------
Institutions européennes: Ensemble d'outils dont le but est de transformer une grande quantité d'argent en merde. Cette merde est utilisée pour créer de nouveaux fonctionnaires. L'argent restant payant des externes pour faire leur travail.
Reply

Marsh Posté le 19-08-2003 à 10:02:22    

En gros, un cluster est à un disque dur ce qu'un pixel est à un écran : c'est la plus petite partie indivisible d'un disque.
 
Ainsi, un fichier remplit au miniumum un cluster, même s'il est plus petit en taille que ce cluster.
 
Hope this helps...


---------------
Mon feedback
Reply

Marsh Posté le 19-08-2003 à 10:03:24    

Merci pour vos réponses !   ;)  
 
Donc normalement lorsque les fichiers seront plus gros (supérieurs à 4 ko sur un système NTFS), il y aura une perte d'espace bien moindre... si j'ai bien compris ?
 
Ou alors il faut peut etre qu'au lieu de 3533 répertoires contenant 12 fichiers chacun, j'organise tout cela un peu différemment ?

Reply

Marsh Posté le 19-08-2003 à 10:12:07    

ça me fait penser... Qu'en est-il sur un cd ou sur tout autre support ? J'imagine que sur disquette on tourne en fat 16 ou 32.
 
Mais sur cd, quelle taille de cluster pour les nombreuses normes qui existent ?

Reply

Marsh Posté le 19-08-2003 à 10:37:51    

benj63 a écrit :

Merci pour vos réponses !   ;)  
 
Donc normalement lorsque les fichiers seront plus gros (supérieurs à 4 ko sur un système NTFS), il y aura une perte d'espace bien moindre... si j'ai bien compris ?
 
Ou alors il faut peut etre qu'au lieu de 3533 répertoires contenant 12 fichiers chacun, j'organise tout cela un peu différemment ?
 


 
Avec des clusters de 4Ko, tu auras toujours au minimum dans les 14Mo utilisés pour tes 3533 folders. Pour gagner de l'espace il va certainement te falloir revoir l'organisation en effet.


---------------
Institutions européennes: Ensemble d'outils dont le but est de transformer une grande quantité d'argent en merde. Cette merde est utilisée pour créer de nouveaux fonctionnaires. L'argent restant payant des externes pour faire leur travail.
Reply

Marsh Posté le 19-08-2003 à 10:39:03    

titre pas conforme + réponse donnée de toute façon.


---------------
Réalisation amplis classe D / T      Topic .Net - C# @ Prog
Reply

Marsh Posté le 19-08-2003 à 13:19:21    

réouverture :jap:
édition du topic attendue.


---------------
Réalisation amplis classe D / T      Topic .Net - C# @ Prog
Reply

Marsh Posté le 19-08-2003 à 13:20:33    

Sachant que je veux faire une base de données stockant des valeurs sans grand rapport entre elles, sans hiérarchie de tables et ne nécessitant pas de requetes complexes, pensez-vous que mes 3500 répertoires avec 12 fichiers (1 par mois) pour chacun d'eux soit une bonne solution ?  :??:  
 
Merci!

Reply

Marsh Posté le 19-08-2003 à 13:20:33   

Reply

Marsh Posté le 19-08-2003 à 14:08:52    

Moi je verrai plutôt un folder par année avec 12 folder mois dans chaque. Après tu peux encore faire qques folders sous les folders mensuels.
 
Mais certaitement pas 3000+ folders ...


---------------
Institutions européennes: Ensemble d'outils dont le but est de transformer une grande quantité d'argent en merde. Cette merde est utilisée pour créer de nouveaux fonctionnaires. L'argent restant payant des externes pour faire leur travail.
Reply

Sujets relatifs:

Leave a Replay

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