Warum ist `du --apparent-size` manchmal um mehr als 90% niedriger?

8

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

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

All dies funktioniert einwandfrei auf meinen lokalen Arch Linux-Boxen, auf denen ich entwickle. Die Pakete, einschließlich ihrer installierten Größe in Bytes (nicht einmal Kilobytes, Bytes!), Werden bei jedem Test genau reproduziert.

Jetzt habe ich diesen Test auch für Travis aktiviert, wo er (soweit ich aus den Travis-Dokumenten weiß) auf einem Ubuntu-12.04-basierten Container ausgeführt wird. Dort besteht der Test meistens. Meistens . Manchmal werden installierte Größen berechnet, die um 80-99% abweichen.

Hier ist ein Beispiel für einen fehlgeschlagenen Test: https://travis-ci.org/holocm/holo/builds/89326780 (Der Test kurz zuvor war erfolgreich.) 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 ohne erkennbares Muster passiert. 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 dort auch keine Muster erkennen, die mir helfen würden, das Problem zu reproduzieren.

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

EDIT: Oh, es gibt tatsächlich ein Muster, das ich beobachtet habe. duwird einmal für jeden Testfall ausgeführt. Wenn es für den ersten Testfall fehlschlägt, schlägt es für alle Testfälle in diesem Lauf fehl.

linux ubuntu disk-usage Stefan Majewsky
quelle
1
Zur Verdeutlichung sind alle Einträge im fraglichen Dateisystembaum einfache zusammenhängende Dateien, Symlinks und Verzeichnisse. Es gibt keine spärlichen Dateien. Es gibt keine Gerätedateien, FIFOs oder andere funky Geschäfte.
Stefan Majewsky
Was sind die Dateisysteme?
Mark Wagner
@ Mark Wagner: Es ist AUFS, laut docs.travis-ci.com/user/workers/container-based-infrastructure
Stefan Majewsky
Einige Möglichkeiten: (1) Die angegebene Größe ist korrekt, aber in einigen Fällen sind einige Dateien von anderen Vorgängen veraltet. (2) Nicht sicher, ob AUFS, aber in NFS werden gelöschte veraltete Dateien in .nfsNNNNNNNN umbenannt, und diese zählen möglicherweise für die Größeninkonsistenz. Wie können Sie sicher sein, dass die angegebenen Größen falsch sind? Können Sie die einzelnen Unterverzeichnisse und Dateien ausprobieren, damit der genaue Ort der Inkonsistenz überprüft werden kann?
Prem
1
Das Problem, das Sie haben, ist AUFS .... Überprüfen Sie die damit verbundenen Probleme, überprüfen Sie die Gründe, warum es nicht in den neuesten Kerneln enthalten ist, überprüfen Sie die "Stabilität" und die "POSIX-Vollständigkeit".
Hvisage

Antworten:

1

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

Das Problem, das Sie haben, ist AUFS .... Überprüfen Sie die damit verbundenen Probleme, überprüfen Sie die Gründe, warum es nicht in den neuesten Kerneln enthalten ist, überprüfen Sie die "Stabilität" und die "POSIX-Vollständigkeit". - Hvisage 24. Januar um 20:55 Uhr

Hvisage
quelle