12Aug
La plupart du temps, les valeurs de 'Taille' et 'Taille sur disque' seront très proches de la correspondance lors de la vérification de la taille d'un dossier ou d'un fichier, mais qu'en est-il s'il y a une énorme différence entre les deux? Le SuperUser Q & A post d'aujourd'hui examine la réponse à ce problème déroutant.
Question d'aujourd'hui &La session de réponse nous est offerte par SuperUser, une subdivision de Stack Exchange, un regroupement communautaire de sites Web Q & A.
La question
SuperUser lecteur thelastblack veut savoir pourquoi il y a une telle différence entre 'Size' et 'Size on disk' pour un dossier sur la carte SD de son téléphone:
Comme vous pouvez le voir ci-dessous, il y a tellement de différence entreLes champs 'Taille' et 'Taille sur disque' pour ce dossier. Pourquoi donc?
Je sais que 'Size on disk' devrait être un peu plus que 'Size' à cause des unités d'allocation dans Windows, mais pourquoi y a-t-il autant de différence? Serait-ce à cause du grand nombre de fichiers?
BTW, ce dossier est sur la carte SD de mon téléphone Android.À l'intérieur, mon application Maps stocke ses cartes mises en cache, et l'application obtient ses cartes de Google Maps.
En regardant la capture d'écran, il y a certainement un énorme décalage entre "Taille" et "Taille sur le disque", alors qu'est-ce qui s'est passé ici pour provoquer cela?
La réponse
SuperUser contributeur Bob a la réponse pour nous:
Je vais supposer que vous utilisez le système de fichiers FAT / FAT32 ici, puisque vous mentionnez ceci est une carte SD.NTFS et exFAT se comportent de la même manière en ce qui concerne les unités d'allocation. D'autres systèmes de fichiers peuvent être différents, mais ils ne sont pas supportés sur Windows de toute façon.
Si vous avez beaucoup de petits fichiers, c'est certainement possible. Considérez ceci:
- 50.000 fichiers
- 32 Ko taille de cluster( unités d'allocation), ce qui est le maximum pour FAT32
Ok, maintenant espace minimum pris est 50,000 * 32,000 = 1,6 Go( en utilisant les préfixes SI, pas binaire, pour simplifiermathématiques).L'espace que chaque fichier occupe sur le disque est toujours un multiple de la taille de l'unité d'allocation - et nous supposons ici que chaque fichier est réellement assez petit pour tenir dans une seule unité, avec un peu d'espace( gaspillé).
Si chaque fichier faisait en moyenne 2 Ko, vous obtiendriez environ 100 Mo au total - mais vous gaspillez en moyenne 15 fois( 30 Ko par fichier) en raison de la taille de l'unité d'allocation.
Explication en profondeur
Pourquoi cela se produit-il? Eh bien, le système de fichiers FAT32 doit garder une trace de l'endroit où chaque fichier est stocké.Si elle devait conserver une liste de chaque octet, la table( comme un carnet d'adresses) se développerait à la même vitesse que les données - et gaspillerait beaucoup d'espace. Donc, ce qu'ils font est d'utiliser des "unités d'allocation", également connu sous le nom de "taille de cluster".Le volume est divisé en ces unités d'allocation, et en ce qui concerne le système de fichiers, ils ne peuvent pas être subdivisés - ce sont les plus petits blocs qu'il peut adresser. Tout comme vous avez un numéro de maison, mais votre facteur ne se soucie pas combien de chambres vous avez ou qui vit en eux.
Alors, que se passe-t-il si vous avez un très petit fichier? Eh bien, le système de fichiers ne se soucie pas si le fichier est de 0 Ko, 2 Ko, ou même 15 Ko, il lui donnera le moins d'espace possible - dans l'exemple ci-dessus, c'est 32 Ko. Votre fichier utilise seulement une petite partie de cet espace, et le reste est essentiellement gaspillé, mais appartient toujours au fichier - un peu comme une chambre que vous laissez inoccupée.
Pourquoi existe-t-il différentes tailles d'unités d'allocation? Eh bien, cela devient un compromis entre avoir une plus grande table( carnet d'adresses, par exemple disant que John possède une maison à 123 Fake Street, 124 Fake Street, 666 Satan Lane, etc.), ou plus d'espace perdu dans chaque unité.Si vous avez des fichiers plus volumineux, il est plus logique d'utiliser des unités d'allocation plus grandes, car un fichier n'obtient pas une nouvelle unité( maison) tant que tous les autres ne sont pas remplis. Si vous avez beaucoup de petits fichiers, eh bien, vous allez avoir une grande table( carnet d'adresses) de toute façon, donc aussi bien leur donner de petites unités( maisons).
Les grandes unités d'allocation, en règle générale, gaspilleront beaucoup d'espace si vous avez beaucoup de petits fichiers. Il n'y a généralement pas de bonne raison d'aller au-dessus de 4 Ko pour un usage général.
Fragmentation?
En ce qui concerne la fragmentation, la fragmentation ne doit pas gaspiller de l'espace de cette manière. Les fichiers volumineux peuvent être fragmentés, c'est-à-dire divisés, en plusieurs unités d'allocation, mais chaque unité doit être remplie avant que la suivante ne soit démarrée. La défragmentation peut économiser un peu d'espace dans les tables d'allocation, mais ce n'est pas votre problème spécifique.
Solutions possibles
Comme l'a suggéré gladiator2345, vos seules vraies options à ce stade sont de le vivre ou de le reformater avec des unités d'allocation plus petites.
Votre carte peut être formatée en FAT16, qui a une limite plus petite sur la taille de la table et nécessite donc des unités d'allocation beaucoup plus grandes pour traiter un plus grand volume( avec une limite supérieure de 2 Go avec des unités d'allocation de 32 Ko).Source avec l'aimable autorisation de Braiam. Si tel est le cas, vous devriez pouvoir formater en toute sécurité comme FAT32 de toute façon.
Avoir quelque chose à ajouter à l'explication? Sonnez dans les commentaires. Vous voulez lire plus de réponses d'autres utilisateurs de Stack Exchange? Découvrez le fil de discussion complet ici.