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

8

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

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

Все это прекрасно работает на моих локальных компьютерах 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, и хотя я видел, что это появляется там один или два раза, я не мог видеть там никаких шаблонов, которые помогли бы мне воспроизвести проблему.

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

РЕДАКТИРОВАТЬ: О, есть один шаблон, который я наблюдал, на самом деле. duзапускается один раз для каждого теста. Когда это терпит неудачу для первого тестового случая, это терпит неудачу для всех тестовых случаев в этом запуске.

Стефан Маевский
источник
1
Для пояснения, все записи в рассматриваемом дереве файловой системы представляют собой простые непрерывные файлы, символические ссылки и каталоги. Там нет разреженных файлов. Там нет файлов устройств, FIFO или каких-либо других интересных дел.
Стефан Маевский
Каковы файловые системы?
Марк Вагнер
@ Марк Вагнер: Это AUFS, согласно docs.travis-ci.com/user/workers/container-based-infrastructure
Стефан Маевски,
Некоторые возможности: (1) указанный размер является правильным, но в некоторых случаях некоторые устаревшие файлы остаются от других операций (2) Не уверен в AUFS, но в NFS удаленные устаревшие файлы будут переименованы .nfsNNNNNNNN, и они могут учитываться для несоответствие размеров. Как вы уверены, что указанные размеры неверны? Можете ли вы попробовать du для отдельных подкаталогов и файлов, чтобы можно было проверить точное местоположение несоответствия?
Прем
1
Проблема, с которой вы столкнулись - это AUFS .... проверьте проблемы, связанные с ней, выясните причины, по которым ее нет в последних версиях ядра, проверьте ее "стабильность", проверьте ее "завершенность POSIX".
Hvisage

Ответы:

1

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

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

Hvisage
источник