Pourquoi «du --apparent-size» est-il parfois moins de 90%?

8

Je travaille sur un logiciel qui construit des packages Pacman (qui sont essentiellement des tarballs avec des fichiers de métadonnées spéciaux). La suite de tests construit certains packages, puis compare le package résultant à un résultat attendu enregistré.

L'un des champs des métadonnées enregistrées dans le package est la taille installée du package, déterminée en exécutant du -s --apparent-sizesur le répertoire racine avant de le tarer.

Tout cela fonctionne parfaitement sur mes boîtiers Arch Linux locaux où je développe. Les packages, y compris leur taille installée en octets (pas même les kilo-octets, les octets!) Sont reproduits exactement à chaque fois que je lance le test.

Maintenant, j'ai également activé ce test sur Travis, où il s'exécute (si je comprends bien de la documentation de Travis) sur un conteneur basé sur Ubuntu-12.04. Là, le test passe la plupart du temps. La plupart du temps. Parfois, il calcule les tailles installées de 80 à 99%.

Voici un exemple de test qui échoue: https://travis-ci.org/holocm/holo/builds/89326780 (Le test juste avant cela a réussi.) L'une des différences pertinentes est

@@ -37,7 +37,7 @@
             pkgdesc = my foo bar package
             url = 
             packager = Unknown Packager
-            size = 37728
+            size = 1464
             arch = any
             license = custom:none
             replaces = foo-bar<2.1

La chose déconcertante à ce sujet est que cela ne se produit que parfois, sans schéma apparent. Le test organise les mêmes fichiers que d'habitude, s'exécute du -s --apparent-sizesur l'arborescence résultante et arrive à un résultat complètement incorrect. J'ai essayé de reproduire cela sur une machine virtuelle Ubuntu 12.04, et même si je l'ai vu y apparaître une ou deux fois, je n'ai pu voir aucun motif émerger non plus qui pourrait m'aider à reproduire le problème.

Peut-être que quelqu'un ici a une idée de ce qui pourrait causer ce problème?

EDIT: Oh, il y a un motif que j'ai observé, en fait. dus'exécute une fois pour chaque testcase. Lorsqu'il échoue pour le premier testcase, il échoue pour tous les testcases de cette exécution.

linux ubuntu disk-usage Stefan Majewsky
la source
1
Pour clarifier, toutes les entrées de l'arborescence du système de fichiers en question sont des fichiers, des liens symboliques et des répertoires contigus simples. Il n'y a pas de fichiers épars. Il n'y a aucun fichier d'appareil, FIFO ou toute autre entreprise géniale.
Stefan Majewsky
Quels sont les systèmes de fichiers?
Mark Wagner
@Mark Wagner: C'est AUFS, selon docs.travis-ci.com/user/workers/container-based-infrastructure
Stefan Majewsky
Quelques possibilités: (1) la taille signalée est correcte, mais dans certains cas, il reste des fichiers périmés provenant d'autres opérations (2) Pas sûr d'AUFS, mais dans NFS, les fichiers périmés supprimés seront renommés .nfsNNNNNNNNN et ceux-ci pourraient compter pour le incohérence de taille. Comment êtes-vous sûr que les tailles signalées sont incorrectes? Pouvez-vous essayer du sur les sous-répertoires et fichiers individuels, de sorte que l'emplacement exact de l'incohérence puisse être vérifié?
Prem
1
Le problème que vous avez est AUFS .... vérifiez les problèmes qui lui sont associés, vérifiez les raisons pour lesquelles il n'est pas dans les derniers noyaux, vérifiez sa «stabilité», vérifiez qu'il est «complétude POSIX».
Hvisage

Réponses:

1

Eh bien, j'ai été invité à mettre cela comme réponse par @derobert

Le problème que vous avez est AUFS .... vérifiez les problèmes qui lui sont associés, vérifiez les raisons pour lesquelles il n'est pas dans les derniers noyaux, vérifiez sa «stabilité», vérifiez qu'il est «complétude POSIX». - Hvisage 24 janvier à 20h55

Hvisage
la source