Question Pourquoi existe-t-il une si grande différence entre "Size" et "Size on Disk"?


Comme vous pouvez le voir ci-dessous, il y a tellement de différence entre Taille et Taille sur le disque champs dans mon dossier. Pourquoi donc?

Screenshot showing 50,875 files in 1,504 folders, 105 MB being 1.43 GB on disk

je le sais Taille sur le disque devrait être un peu plus que Taille en raison des unités d'allocation dans Windows, mais pourquoi une telle différence? Pourrait-il être à cause du grand nombre de fichiers?

BTW, ce dossier est sur la carte SD de mon téléphone Android. À l'intérieur de cela, mon application Cartes stocke ses cartes en cache et l'application obtient sa carte à partir de Google Maps.


295
2018-01-20 09:48


origine


Bonjour thelastblack, et bienvenue dans SuperUser. J'ai modifié votre question pour supprimer le problème de la défragmentation, car les deux réponses existantes se concentrent sur la taille / taille de la différence de disque et le format Stack Exchange fonctionne mieux lorsque chaque question publiée concerne une seule chose. Vous pouvez certainement poser cette question séparément, bien que je pense que les réponses que vous avez reçues jusqu'à présent sur cette question montrent que la défragmentation ne vous sera d'aucune aide. (En général, cela ne marche pas bien sur les supports à semi-conducteurs.) N'hésitez pas à modifier votre question plus loin si vous sentez que j'ai changé votre intention de quelque manière que ce soit. - Michael Kjörling
@ MichaelKjörling Heh, je viens d'éditer dans une discussion mineure sur la fragmentation (distrait un peu plus tôt) - Bob
@ MichaelKjörling Ne pas éditez les questions rétroactivement pour adapter les réponses. L'une des réponses aborde la question de la fragmentation de la question des OP. Votre modification doit être annulée pour éviter toute confusion. - DanteTheEgregore
@DanteTheEgregore Si vous vous référez à la réponse de Bob, qui a en effet été modifiée pour discuter également des effets de la fragmentation, avant de lancer l'arme, veuillez vérifier les historiques et horodatages de cette réponse et la question. Au moment de mon édition, la réponse de Bob ne couvrait pas du tout la question de la fragmentation. Si l'OP veut le faire, éditer à nouveau "la défragmentation des médias m'aidera-t-elle?" devrait résoudre toute confusion en suspens, même si je me sens toujours il vaut mieux poser cette question séparément; IMO la question de la différence entre les deux valeurs est sans rapport. - Michael Kjörling
Il me semble que cette application est sérieusement programmée - envisagez de déposer un rapport de bogue. Je ne suis en aucun cas un programmeur professionnel, mais j’ai déjà piraté quelque chose de similaire dans JavaME, et bien sûr, l’un des problèmes que j’ai dû résoudre était de stocker efficacement ces petites cartes (stockage et accès) dans un conteneur. J'ai fini par utiliser des fichiers zip non compressés. - A. Donda


Réponses:


Je suppose que vous utilisez le système de fichiers FAT / FAT32 ici, puisque vous mentionnez qu'il s'agit d'une carte SD. NTFS et exFAT se comportent de la même manière en ce qui concerne les unités d'allocation. Les autres systèmes de fichiers peuvent être différents, mais ils ne sont de toute façon pas pris en charge sous Windows.

Si vous avez beaucoup de petits fichiers, cela est certainement possible. Considère ceci:

  • 50 000 fichiers.

  • Taille de cluster de 32 Ko (unités d'allocation), qui correspond au maximum pour FAT32

Ok, maintenant le le minimum l'espace occupé est de 50 000 * 32 000 = 1,6 Go (en utilisant des préfixes SI, pas binaires, pour simplifier les calculs). L'espace pris par chaque fichier sur le disque est toujours un multiple de la taille de l'unité d'allocation - et nous supposons ici que chaque fichier est suffisamment petit pour tenir dans une seule unité, avec un espace (perdu) restant.

Si chaque fichier avait une moyenne de 2 Ko, vous obtiendriez environ 100 Mo au total, mais vous perdez en moyenne 15 fois plus (30 Ko par fichier) en raison de la taille de l'unité d'allocation.


Explication approfondie

Pourquoi cela arrive-t-il? Eh bien, le système de fichiers FAT32 doit garder la trace de l'emplacement de chaque fichier. Si elle devait conserver une liste de chaque octet, la table (comme un carnet d’adresses) augmenterait à la même vitesse que les données et gaspillerait beaucoup d’espace. Ainsi, ils utilisent des "unités d'allocation", également appelées "taille de cluster". Le volume est divisé en ces unités d’allocation et, en ce qui concerne le système de fichiers, elles ne peuvent pas être subdivisées - ce sont les plus petits blocs qu’il peut traiter. Tout comme vous avez un numéro de maison, mais votre facteur ne se soucie pas du nombre de chambres que vous avez ou qui y habite.

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 de savoir si le fichier est 0 Ko, 2 Ko ou même 15 Ko, cela lui donnera le moins d'espace possible - dans l'exemple ci-dessus, cela fait 32 Ko. Votre fichier n'utilise qu'une petite partie de cet espace, et le reste est essentiellement gaspillé, mais appartient toujours au fichier - un peu comme une chambre inoccupée.

Pourquoi existe-t-il différentes tailles d'unités d'allocation? Eh bien, cela devient un compromis entre avoir une table plus grande (carnet d'adresses, par exemple disant que John possède une maison au 123 Fake Street, 124 Fake Street, 666 Satan Lane, etc.) ou plus d'espace perdu dans chaque unité (maison). Si vous avez des fichiers plus volumineux, il est plus judicieux d'utiliser des unités d'allocation plus importantes, car un fichier ne reçoit pas une nouvelle unité (house) 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, 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’ya généralement pas de raison de dépasser 4 kB pour une utilisation générale.


Fragmentation?

En ce qui concerne la fragmentation, la fragmentation ne devrait 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 lancé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 gladiateur2345 suggéré, vos seules options réelles à ce stade sont de vivre avec ou de reformater avec des unités d’allocation plus petites.

Votre carte peut être formatée en FAT16, ce qui limite la taille de la table et nécessite par conséquent des unités d'allocation beaucoup plus importantes pour traiter un volume plus important (avec une limite supérieure de 2 Go avec des unités d'allocation de 32 Ko). La source courtoisie de Braiam. Si tel est le cas, vous devriez pouvoir formater le FAT32 en toute sécurité.


299
2018-01-20 09:54



L’espace gaspillé en raison des tailles d’allocation minimales est en fait techniquement appelé «fragmentation interne». pourrait dire que la fragmentation est le coupable. Mais ce n'est toujours pas quelque chose que n'importe quel outil de "défragmentation" peut faire. - hobbs
(Moins techniquement, on l'appelle simplement "slack".) - hobbs
Les tailles de cluster limitent également la taille maximale du système de fichiers. Par exemple, si votre espace d'adressage est 32 bits, vous avez un total d'environ 4,29 milliards de clusters totaux possibles. Maintenant, si vous utilisez la plus petite taille de cluster prise en charge par NTFS (512 octets), vous pouvez traiter un maximum de 512 * 2 ^ 32 octets = 2 Gio. Si vous avez besoin d'un volume capable de stocker plus de 2 Gio de données, vous devez augmenter la taille du cluster. Tout cela est indépendant du fichier le plus volumineux que vous tentez de stocker, car vous ne pouvez pas stocker un fichier de plus de 2 Gio, le moindre de vos problèmes. - Andon M. Coleman
4 clusters KiB vous permettront d’adresser des fichiers d’une taille allant jusqu’à 16 TiB, ce qui devrait suffire dans un avenir prévisible. - Andon M. Coleman
Eh bien, il pourrait compresser ses archives de petits fichiers en un seul gros fichier. - einpoklum


C'est l'une des situations où la compression / archivage dans un seul fichier peut aider. Quelle Bob a dit dans sa réponse est vrai mais la solution peut être plus facile que de reformater le disque comme le suggèrent d’autres réponses. Si vous compressez ou archivez le répertoire (en utilisant zip, tar ou toute autre méthode), le système de fichiers verra que vous avez un seul gros fichier, au lieu de plusieurs plus petits. Même sans compression, vous récupérerez près de 1,4 Gbit d'espace, car tous ces "petits fichiers" seront considérés comme un seul gros fichier.

À l'intérieur de cela, mon application de cartes stocke ses cartes en cache et l'application obtient sa carte à partir de Google Maps.

Peut-être devriez-vous discuter avec le développeur pour utiliser une archive ou une base de données au lieu de plusieurs fichiers. Cela aidera probablement aussi à avoir le disque moins fragmenté et économisera sûrement de l’espace, surtout si c’est un lecteur flash NAND. Si vous expliquez la situation ridicule dans laquelle 100 Mo de données utiles / utiles deviennent 1.4GiB, il y a quelque chose qui ne va pas dans la façon dont les données sont stockées, et les développeurs doivent apporter une solution plus agréable.


46
2018-01-20 15:03



> À l’intérieur de cette application, l’application Maps stocke ses cartes en cache et l’application obtient sa carte à partir de Google Maps. - malheureusement, dans ce cas, la compression (qui est en fait un système de fichiers supérieur à celui de base) nécessiterait un support de cette application cartographique. - Bob
@Bob alors la solution devrait venir du côté développeur D: - Braiam
C'est totalement vrai. Je pense que pour le moment, je devrais changer d’application. - vfsoraki
@Braiam Il ne fait pas croire au système de fichiers qu’il n’ya qu’un seul fichier; Là est un seul fichier. Quant aux raisons pour lesquelles les développeurs ne stockent pas les informations de cache dans une archive, c'est probablement parce que la plupart des formats d'archive ne sont pas conçus pour des écritures aléatoires rapides, ce dont le cache a certainement besoin. Une meilleure alternative pourrait être d'utiliser une bibliothèque de base de données légère comme SQLite. - bcrist
Absolument vrai ..... +1 - arundevma


Si quelqu'un est confronté à ce problème, il peut être utile de savoir qu'une autre raison de voir une grande différence de taille de fichier / d'espace sur le disque est l'utilisation de flux de données alternatifs (LES PUBLICITÉS)

Ceci s'applique uniquement à NTFS à ma connaissance. Les ADS sont connus pour des utilisations légitimes et non légitimes:

  • baliser un fichier comme téléchargé depuis Internet
  • stocker des métadonnées (Microsoft voulait inclure une partie de la fonctionnalité Apple OS, comme ne pas utiliser l'extension de fichier pour déterminer le type d'un fichier)
  • masquer des données ou du code dans le contexte d'un malware.

ADS simplement: tout fichier NTFS peut contenir plusieurs flux de données (comprendre les "sous-fichiers"). L'un est le flux principal, utilisé par Windows Explorer et d'autres outils Windows, il contient le contenu habituel d'un fichier. Les flux de données alternatifs peuvent contenir d'autres informations, exactement comme le flux principal, mais ils ne peuvent pas être gérés directement par les outils Windows (en particulier Explorer affiche la taille du fichier égale à la taille du flux principal, quelle que soit la taille de l'ADS). Vous devez utiliser des outils spécialisés ou du code pour écrire, lire et localiser les ADS.

Le point principal est que, en cas de grande différence de taille de fichier observée, ne négligez pas la possibilité de l’ADS et des logiciels malveillants cachés.

Un autre lien.

Pour tester en toute sécurité avec ADS, essayez ceci au niveau DOS / CMD ...

Créez puis affichez le contenu d'un fichier à la racine de C:

C:\> echo The main data stream> test.txt
C:\> type test.txt

Résultat:

C:\> The main data stream

Ajoutez maintenant un ADS avec la même méthode, spécifiez simplement le nom ADS en plus du nom de fichier:

C:\> echo The secret message> test.txt:secret

Vous venez de masquer le message secret dans le fichier. Notez que la taille du fichier dans l'explorateur n'a pas changé malgré l'ajout d'octets dans le "secret" ADS.

Essayez d'afficher le contenu ADS:

C:\> type test.txt:secret

Résultat:

The filename, directory name, or volume label syntax is incorrect.

CMD type n'est pas en mesure d'afficher le contenu de l'ADS. Nous allons utiliser Notepad à la place:

notepad test.txt:secret

Dans le Bloc-notes, nous pouvons voir le contenu de l’ADS:

The secret message

Vous pouvez également masquer un fichier exécutable complet dans un fichier ADS d'un fichier texte innocent et l'exécuter à tout moment. La richesse ne nuit pas aux pirates :-)


25
2018-01-21 07:37



Je ne suis pas un homme gagnant moi-même, mon travail se fait principalement sous Linux. C'était très utile. Je vous remercie - vfsoraki
Il est utile d'utiliser un outil tel que Streams from Sysinternals pour vérifier l'utilisation de l'ADS. Par exemple, les fichiers téléchargés sur un système Windows peuvent être étiquetés avec une source dans ADS, bien que cela soit minime et ne devrait pas prendre de place. Il ne sera pas affiché dans dir ou Explorer sortie normalement. Cela peut prendre des blocs et aggraver le problème d'utilisation du disque que vous étudiez. . - adric


Le problème peut être dû à la taille du cluster.

Selon Microsoft:

Si vous n'utilisez pas la compression NTFS pour des fichiers ou des dossiers   contenu sur le volume, la différence entre la taille et la taille sur le disque   est un espace perdu en raison d'une taille de cluster plus grande que nécessaire. Toi   devrait essayer d'utiliser une taille de cluster optimale pour que la taille sur le disque   La valeur est aussi proche que possible de la valeur SIZE. Un excès   la différence entre la taille sur le disque et la valeur de la taille est un   indication que la taille de cluster par défaut est trop grande pour la moyenne   taille du fichier que vous stockez sur le volume, et qu'il devrait être   diminué. Cela ne peut être fait qu'en sauvegardant le volume puis   reformater le volume à l'aide de la commande format et du commutateur / a   pour spécifier la taille d'allocation appropriée: IE: format D: /a:2048   (Cet exemple utilise une taille de cluster de 2 Ko).

Essayez de formater votre lecteur avec une taille de cluster plus petite.


19
2018-01-20 09:57



Cela étant dit, il ne faut pas que la taille du cluster soit inférieure à 4096 octets ou simplement pas multiple de ce nombre. Le système d'exploitation 32 bits fonctionne avec des pages de 4096 octets (dans les cas non PAE). L'utilisation de clusters non multiples peut donc affecter les performances du système de fichiers. C'est pourquoi la taille par défaut est définie sur 4096 octets. - Ruslan
Pour ajouter à ce que @Ruslan a déclaré, les nouveaux disques durs ont désormais une taille de secteur de 4 Ko, et il serait optimal d’aligner le système de fichiers sur les secteurs physiques et d’avoir un multiple de la taille du secteur physique. - Bob
@Ruslan Je pense que vous voulez dire que ce devrait être une puissance de deux fois 4096. 12288 (3 × 4096) et 20480 (5 × 4096) ne sont pas de bons choix. - Scott


Je vois beaucoup de personnes recommandant de reformater votre disque avec une taille de cluster plus petite. Puisqu'il s'agit d'une carte SD, notez que de nombreux fournisseurs pré-formatent la carte à la taille de cluster recommandée pour correspondre à la taille de la grappe de la NAND (les deux sont synchronisés). très important pour des performances optimales de lecture / écriture et pour réduire l'usure

Vous ne pouvez pas changer la taille du cluster de la NAND (c'est un attribut physique du matériel de votre carte SD).

Exécutez d'abord scandisk / chkdsk sur votre carte SD pour vous assurer que le problème de rapport de taille ne réside pas dans un système de fichiers corrompu.

Deuxièmement, je vous suggère de signaler le bogue aux développeurs de Google Map, car c’est eux qui sont à blâmer ici. Ils devraient utiliser une méthode de stockage supérieure. La réparer devrait également permettre à l'application de s'exécuter plus rapidement sur de nombreux appareils en raison de la diminution des activités d'E / S et du pilote de système de fichiers.


9
2018-01-21 18:20



En fait, ce n'était pas Google Maps, mais une autre application utilisant les cartes de Google. J'ai informé le développeur et j'ai simplement retiré ces fichiers de ma SD. - vfsoraki


Ceci est un problème général avec de nombreux systèmes de fichiers. Deux facteurs sont à prendre en compte, à savoir le nombre maximal de "blocs" qu'un système de fichiers peut gérer par volume logique et restrictions physiques du support de stockage. Un seul fichier peut être attribué à un bloc donné (les fichiers nécessitent généralement autant de blocs que nécessaire). Ainsi, un fichier texte de 64 octets peut prendre de 4 à 32 Ko, en fonction de la taille du système de fichiers sur lequel il se trouve.

Une façon de penser à cela est de penser à chaque bloc du système de fichiers en tant que boîte et au système de fichiers en tant que pièce. Toutes vos boîtes sont de la même taille et vous essayez de les adapter autant que possible dans une pièce. Si vous les rangez tous avec plus d'espace, vous devez obtenir des boîtes plus grandes pour que la pièce soit complètement remplie de boîtes.

Une des règles pour mettre des choses dans des boîtes est que vous ne pouvez pas mettre deux choses sans rapport dans une boîte. Ils doivent faire partie du même document. Donc, si je devais taper une page de texte, elle aurait sa propre boîte. Si mon texte tapé avait tellement de pages que je ne pouvais pas tout insérer dans une seule boîte, je trouverais simplement une autre boîte et continuerais à y mettre des pages, en répétant jusqu'à ce que toutes mes pages soient classées. J'avais également écrit les boîtes que j'avais utilisées pour ce document et l'ordre des boîtes pour le lire en séquence.

En fonction de la manière dont j'organiserais les boîtes, il se peut que je dispose de suffisamment de place dans mon manifeste pour un certain nombre de boîtes. Donc, si j'avais une grande salle à remplir, mais seulement un petit nombre de boîtes, je devrais utiliser de très grandes boîtes pour atteindre la capacité de la pièce.

Donc, dans ce cas, mon document d'une page occuperait toujours une seule boîte, sans rien partager d'autre.

Les mêmes situations se produisent parmi les différentes solutions de stockage. FAT32 ne peut gérer que ce qui est considéré comme un faible nombre de "boîtes" sur les énormes disques durs d'aujourd'hui, ce qui se traduit par de très grandes "boîtes" pour compenser cela.


7
2018-01-20 14:50





Outre les tailles de cluster, vous pouvez également avoir une divergence due aux conditions suivantes:

  • Les fichiers compressés ou chiffrés peuvent utiliser un espace différent de celui de la taille du fichier logique.
  • Les fichiers liés rapporteront n multiplié par le nombre de liens multiplié par la taille du fichier pour la taille du fichier logique, mais l'espace physique utilisé est généralement inférieur.

6
2018-01-20 17:42



En général, cela pourrait être vrai. Mais dans mon cas, l’unité à forte allocation était le problème. - vfsoraki
Ouais j'essaie juste d'ajouter à la réponse en donnant plus de raisons possibles pour la différence. - Archimedes Trajano


Vous devriez jeter un coup d’œil à l’entrée Block Suballocation dans Wikipedia. C'est exactement ce qui vous arrive. L'utilisation d'un système de fichiers prenant en charge Tail Packaging est une solution au niveau du système de fichiers pour ce problème, en plus de la modification de la taille des clusters d'allocation.

Tous ont l'inconvénient de devoir reformater le disque.

Dans certains cas, le simple stockage de ces fichiers dans une archive résoudrait le problème (et les petits fichiers seraient également compressés à côté de l'arrêt de la perte d'espace à la fin des fichiers). Cela a l'inconvénient de passer du temps pour la décompression.

Une autre option si vous avez tant de petits fichiers en raison d'un problème spécifique lié à l'application est de stocker vos données logicielles en utilisant une autre méthode (peut-être dans une base de données). Mais bien sûr, c'est une solution pour les programmeurs, pas pour les utilisateurs finaux.

http://en.wikipedia.org/wiki/Tail_packing


6
2018-01-20 15:00