Perché `du --apparent-size` è talvolta disattivato di oltre il 90%?


8

Sto lavorando a un software che costruisce pacchetti Pacman (che fondamentalmente sono tarball con alcuni file di metadati speciali). La suite di test crea alcuni pacchetti, quindi confronta il pacchetto risultante con un risultato previsto registrato.

Uno dei campi nei metadati registrati nel pacchetto è la dimensione installata del pacchetto, determinata eseguendo du -s --apparent-sizenella directory principale prima di tararlo.

Tutto questo funziona perfettamente sui miei box Arch Linux locali in cui sviluppo. I pacchetti, comprese le dimensioni installate in byte (nemmeno kilobyte, byte!) Vengono riprodotti esattamente ogni volta che eseguo il test.

Ora ho anche abilitato questo test su Travis, dove viene eseguito (per quanto ho capito dai documenti Travis) su un contenitore basato su Ubuntu-12.04. Lì, il test passa la maggior parte delle volte. Il più delle volte. A volte, calcola le dimensioni installate che sono disattivate dell'80-99%.

Ecco un esempio di test che non ha esito positivo : https://travis-ci.org/holocm/holo/builds/89326780 (Il test appena precedente ha avuto esito positivo.) Una delle differenze rilevanti è

@@ -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 cosa sconcertante di questo è che succede solo qualche volta, senza un modello apparente. Il test organizza gli stessi file di sempre, viene eseguito du -s --apparent-sizesull'albero risultante e arriva a un risultato completamente sbagliato. Ho provato a riprodurlo su una macchina virtuale Ubuntu 12.04 e mentre l'ho visto apparire lì una o due volte, non sono riuscito a vedere alcun modello emergere lì che mi avrebbe aiutato a riprodurre il problema.

Forse qualcuno qui ha un'idea di cosa potrebbe causare questo problema?

EDIT: Oh, c'è uno schema che ho osservato, in realtà. duviene eseguito una volta per ogni testcase. Quando fallisce per il primo testcase, fallirà per tutti i testcase in questa corsa.


1
Per chiarire, tutte le voci nella struttura del filesystem in questione sono semplici file contigui, collegamenti simbolici e directory. Non ci sono file sparsi. Non ci sono file di dispositivo, FIFO o altre attività funky.
Stefan Majewsky,

Quali sono i filesystem?
Mark Wagner,


Alcune possibilità: (1) le dimensioni riportate sono corrette, ma in alcuni casi rimangono alcuni file obsoleti rimanenti rispetto ad altre operazioni (2) Non sono sicuro di AUFS, ma in NFS, i file non aggiornati cancellati verranno rinominati .nfsNNNNNNNN e questi potrebbero contare per incoerenza dimensionale. Come sei sicuro che le dimensioni riportate non siano corrette? Puoi provare du sulle singole sottodirectory e file, in modo da poter verificare l'esatta posizione di incoerenza?
Prem

1
Il problema che hai è AUFS .... controlla i problemi ad esso associati, controlla i motivi per cui non è negli ultimi kernel, controlla che sia "stabilità", controlla che sia "completezza POSIX".
Hvisage

Risposte:


1

Bene, mi è stato chiesto di inserire questo come risposta da @derobert

Il problema che hai è AUFS .... controlla i problemi ad esso associati, controlla i motivi per cui non è negli ultimi kernel, controlla che sia "stabilità", controlla che sia "completezza POSIX". - Hvisage 24 gennaio alle 20:55

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.