4 votes

MagicKat avatar

Désaccord sur la taille du fichier

Demandé el 10 de Septembre, 2009
Quand la question a-t-elle été
2710 affichage
Nombre de visites la question a
4 Réponses
Nombre de réponses aux questions
Résolu
Situation réelle de la question

Quelle est la raison de la différence entre les tailles de fichiers rapportées ?

[root@localhost]# ls -lah sendlog
-rw-rw-r-- 1 mail mail 1.3T Aug 15 17:30 sendlog

[root@localhost]# du -m sendlog
24M  sendlog

Nous avons pris conscience de ce problème lorsque la sauvegarde d'un serveur échouait constamment en raison de problèmes de quotas, de sorte que ce n'était pas seulement "ls" qui voyait cette taille erronée.

Des termes tels que "sparse files" et "block assignment" me viennent à l'esprit, mais je ne suis pas sûr de la raison pour laquelle cela se produit ou de la véritable raison derrière cela. Il y a manifestement une différence dans la façon dont les deux commandes vérifient la taille, ai-je raison de toujours faire confiance à du ?

Pour information, il devrait s'agir d'un fichier journal de courrier assez standard.

Demandé el 10 de Septembre, 2009 par MagicKat

0 votes

Avatar de Utilisateur non enregistré

Se pourrait-il que le fichier soit toujours en cours d'écriture ? Du point de vue de Windows, si j'écris dans un grand fichier, l'affichage de l'explorateur indiquera 0 octet, alors qu'un outil comme Contig indiquera la taille réelle.

Commenté el 10 de Septembre, 2009 par Utilisateur non enregistré

1 votes

Avatar de radius

Pourriez-vous nous montrer les sorties de df -k, ls -l sendlog (sans -h) et stat sendlog ?

Commenté el 10 de Septembre, 2009 par radius

1 votes

Avatar de radius

Et le type de système de fichiers s'il vous plaît.

Commenté el 10 de Septembre, 2009 par radius
Afficher 1 autres commentaires

Réponses

Trop de publicités?

10voto

dF. avatar
dF. Points 29787

La différence entre ces valeurs est la suivante.

Du manuel de stat(2)

struct stat {
    // snip
    off_t     st_size;    /* total size, in bytes */
    // snip
    blkcnt_t  st_blocks;  /* number of blocks allocated */
    // snip
};

Le champ st_blocks indique le nombre de blocs alloués au fichier fichier, par unités de 512 octets. (Ce nombre peut être plus petit que st_size/512, par exemple, lorsque le fichier comporte des trous).

La taille telle que rapportée par ls est st_size la taille telle que rapportée par du est st_blocks * 512

La valeur indiquée par du est le nombre d'octets utilisés par le fichier sur le système de fichiers/disque, et la valeur indiquée par ls est la taille/longueur réelle du fichier lorsque vous interagissez avec lui. (En plus de fonctionner avec l'utilisation sur le disque, du ne compte qu'une seule fois les fichiers en dur).

La valeur qui est la "bonne" dépend du contexte. Si vous recherchez l'utilisation du disque, du est correct, si vous vous demandez combien d'octets contient le fichier, ls/ st_size est correct.

En outre, vous pouvez en utilisant diverses options obtenir par exemple du (--apparent-size) d'utiliser la taille rapportée par st_size ou vous pouvez obtenir ls (-s) pour rapporter le nombre de blocs utilisés.

Votre hypothèse concernant le fait que votre fichier journal soit un fichier épars semble plausible, cependant, la raison pour laquelle je ne sais pas.

Répondu el 10 de Septembre, 2009 par dF. (29787 Points )

3voto

Dot Net Pro UK avatar
Dot Net Pro UK Points 761

Comme Kjetil l'a expliqué, vous avez un fichier épars. Les blocs de données vierges à l'intérieur du fichier ne sont pas alloués au disque jusqu'à ce que vous écriviez réellement dans ces blocs. Comment cela est arrivé dans un fichier journal est un mystère. Vous devez vérifier vos journaux d'audit à partir de la dernière fois où sendlog avait une taille correcte jusqu'au moment où il avait ce trou énorme. La réponse se trouve peut-être dans le fichier journal lui-même.

Peut-être que quelqu'un a fait ça intentionnellement pour causer des ravages dans votre système. Ou c'était une erreur logicielle.

Vous pouvez créer facilement votre propre fichier de la taille d'un téraoctet avec :

dd if=/dev/zero of='OMG_Thats_a_1_terabyte_file!!.dat' seek=1T bs=1 count=1

Ce fichier n'allouera que quelques kilo-octets d'espace disque dans toute version actuelle de Linux avec un système de fichiers prenant en charge les fichiers épars.

Votre solution de sauvegarde a besoin d'être remplacée. Tout système de sauvegarde sérieux gère aujourd'hui efficacement les fichiers épars. Même la solution la plus simple utilisant GNU tar le supporte (option -S ou --sparse).

Répondu el 10 de Septembre, 2009 par Dot Net Pro UK (761 Points )

0voto

wRAR avatar
wRAR Points 293

Peut-être que votre du ne supporte pas de si grands nombres ?

Répondu el 10 de Septembre, 2009 par wRAR (293 Points )

0 votes

Avatar de radius

Vous pensez vraiment qu'il a un fichier journal de 1.3TB ? ..

Commenté el 10 de Septembre, 2009 par radius

0 votes

Avatar de MagicKat

C'est seulement un disque dur de 120GB :)

Commenté el 10 de Septembre, 2009 par MagicKat

0voto

igustin avatar
igustin Points 355

Votre système de fichiers pourrait être corrompu (ou le disque a des problèmes physiques). Vous devriez faire un fsck dès que possible (sur une partition non montée) et voir ce qui se passe avec ces chiffres par la suite.

Répondu el 10 de Septembre, 2009 par igustin (355 Points )

Questions en vedette

Top Tags

Dans notre réseau

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

Yandex
X