Je compilais un noyau personnalisé et je voulais tester la taille du fichier image. Ce sont les résultats:
ls -la | grep vmlinux -rwxr-xr-x 1 root root 8167158 May 21 12:14 vmlinux du -h vmlinux 3.8M vmlinux size vmlinux text data bss dec hex filename 2221248 676148 544768 3442164 3485f4 vmlinux
3 Réponses :
Ils sont tous corrects, ils montrent simplement différentes tailles. P>
ls code> montre la taille du fichier (lorsque vous ouvrez et lisez-la, c'est combien d'octets vous obtiendrez) li>
-
du code> montre une utilisation réelle du disque pouvant être inférieure à la taille du fichier en raison de trous li>
-
Taille code> montre la taille de l'image d'exécution d'un objet / exécutable qui n'est pas directement liée à la taille du fichier (BSS n'utilise aucun octetage dans le fichier, quel que soit le fichier, le fichier peut contiennent des informations de débogage qui ne font pas partie de l'image d'exécution, etc.) li>
ul>
Si vous voulez savoir combien de RAM / ROM une exécutable prendra à l'exclusion de l'allocation de mémoire dynamique, Taille Code> vous donne les informations dont vous avez besoin. P>
Taille Code> donne de bonnes informations pour un binaire régulier. Je pense que vous voudriez regarder un fichier de carte pour le noyau Linux. Par exemple, .init i> Les sections sont supprimées après la première exécution, etc. Il peut y avoir Détendez-vous i> Tables, etc. QUI
Taille CODE> MAI ou peut ne pas traiter avec.
Deux définition doivent être comprises
1 Runtime VS StoreTime (c'est pourquoi 2 Profondeur de fichier vs répertoire vs (C'est pourquoi Regardez sur l'exemple ci-dessous: p> si vous utilisez Taille code> diffère) p>
DU code> diffère) p>
Taille code> non sur l'exécutable,
Les différences empiriques se produisent le plus souvent pour des fichiers rares et des fichiers compressés et peuvent aller dans les deux sens.
Les fichiers clairsemés contiennent des métadonnées sur l'espace nécessaire à une application, que LS lit et s'applique pour son résultat, tandis que DU NON. Par exemple: P>
truncate -s 1m test.dat
d'autre part peut indiquer, comme dans votre cas, des fichiers qui pourraient occuper beaucoup d'espace sur disque (c.-à-d. Ils se sont propagés entre de nombreux blocs), mais tous les blocs sont remplis, c'est-à-dire leur Bytesize (mesuré par LS) est plus petit que DU (en regardant des blocs occupés). J'ai observé cet exemple plutôt clairement. pour certains fichiers de cornichons Python. p> p>
Qu'est-ce que
stat vmlinux code> imprimé?
ls code> signalez la taille de disque sur disque, qui n'a rien à voir avec ce que
taille code> signale.
DU CODE> signalez le même numéro, vient de convertir en mégaoctets au lieu d'octets. @pavel:
ls code> utilise stat () en interne. Il n'y a pas de différence entre les deux, autres que la manière dont les informations sont présentées.
Comment 8167158 égal à 3,8 m ??