Почему «du -apparent-size» иногда отключается более чем на 90%?

Я работаю над программным обеспечением, которое создает пакеты Pacman (в основном это tarballs с некоторыми специальными файлами метаданных). Набор тестов создает некоторые пакеты, а затем сравнивает полученный пакет с записанным ожидаемым результатом.

Одним из полей в метаданных, записанных в пакете, является установленный размер пакета, определяемый запуском du -s --apparent-size в корневом каталоге до его tar.

Все это прекрасно работает на моих локальных ящиках Arch Linux, где я развиваюсь. Пакеты, включая их установленный размер в байтах (даже килобайты, байты!), Воспроизводятся точно каждый раз, когда я запускаю тест.

Теперь я также включил этот тест в Travis, где он работает (насколько я понимаю из документов Travis) на контейнере на основе Ubuntu-12.04. Там тест проходит большую часть времени. В большинстве случаев. Иногда он вычисляет установленные размеры, которые отключены на 80-99%.

Ниже приведен пример неудачного теста: https://travis-ci.org/holocm/holo/builds/89326780 (Тест перед тем, как это удалось.) Один из соответствующих различий

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

Загадочная вещь в этом заключается в том, что это происходит только иногда, без видимой картины. Тест организует те же файлы, что и всегда, запускает du -s --apparent-size в полученном дереве и достигает совершенно неправильного результата. Я попытался воспроизвести это на Ubuntu 12.04 VM, и хотя я видел, что он появился там один или два раза, я не видел, чтобы какие-либо шаблоны появлялись там, что помогло бы мне воспроизвести проблему.

Может быть, у кого-то есть идея, что может вызвать эту проблему?

EDIT: О, есть одна картина, которую я наблюдал, на самом деле. du запускается один раз для каждого теста. Когда он завершится неудачно для первого тестового теста, он будет терпеть неудачу для всех тестовых таблиц в этом прогоне.

Ну, мне было предложено поставить это как ответ от @derobert

Проблема у вас – это AUFS …. проверьте связанные с ней проблемы, проверьте причины, по которым это не в последних ядрах, проверьте, что это «стабильность», проверьте, что это «полнота POSIX». – Hvisage 24 января в 20:55