Warum weicht „du --apparent-size“ manchmal um mehr als 90 % ab?

Warum weicht „du --apparent-size“ manchmal um mehr als 90 % ab?

Ich arbeite an einer Software, die Pacman-Pakete erstellt (im Grunde Tarballs mit einigen speziellen Metadatendateien). Die Testsuite erstellt einige Pakete und vergleicht dann das resultierende Paket mit einem aufgezeichneten erwarteten Ergebnis.

Eines der Felder in den im Paket aufgezeichneten Metadaten ist die installierte Größe des Pakets. Diese wird durch Ausführen du -s --apparent-sizeim Stammverzeichnis vor dem Tarieren ermittelt.

All dies funktioniert auf meinen lokalen Arch Linux-Rechnern, auf denen ich entwickle, einwandfrei. Die Pakete, einschließlich ihrer installierten Größe in Bytes (nicht einmal Kilobytes, sondern Bytes!), werden jedes Mal, wenn ich den Test ausführe, exakt reproduziert.

Nun habe ich diesen Test auch auf Travis aktiviert, wo er (soweit ich die Travis-Dokumentation verstehe) auf einem Ubuntu-12.04-basierten Container läuft. Dort ist der Test in den meisten Fällen erfolgreich.Am meistender Fälle. Manchmal werden installierte Größen berechnet, die um 80-99 % abweichen.

Hier ist ein Beispiel für einen Test, der fehlschlägt:https://travis-ci.org/holocm/holo/builds/89326780(Der Testkurz davorerfolgreich.) Einer der relevanten Unterschiede ist

@@ -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

Das Rätselhafte daran ist, dass es nur manchmal passiert und kein erkennbares Muster aufweist. Der Test ordnet dieselben Dateien wie immer an, läuft du -s --apparent-sizeauf dem resultierenden Baum und kommt zu einem völlig falschen Ergebnis. Ich habe versucht, dies auf einer Ubuntu 12.04-VM zu reproduzieren, und obwohl ich es dort ein- oder zweimal gesehen habe, konnte ich auch dort keine Muster erkennen, die mir bei der Reproduktion des Problems geholfen hätten.

Vielleicht hat hier jemand eine Idee, was dieses Problem verursachen könnte?

EDIT: Oh, es gibt tatsächlich ein Muster, das mir aufgefallen ist. duwird einmal für jeden Testfall ausgeführt. Wenn es beim ersten Testfall fehlschlägt, wird es bei diesem Durchlauf bei allen Testfällen fehlschlagen.

Antwort1

Nun, ich wurde von @derobert dazu aufgefordert, dies als Antwort zu posten

Das Problem, das Sie haben, ist AUFS.... prüfen Sie die damit verbundenen Probleme, prüfen Sie die Gründe, warum es nicht in den neuesten Kerneln enthalten ist, prüfen Sie seine „Stabilität“, prüfen Sie seine „POSIX-Vollständigkeit“. – Hvisage 24. Jan. um 20:55

verwandte Informationen