Отправка ZFS объема 1,6 ГБ приводит к ОГРОМНОМУ файлу — виновата фрагментация?
Возможно, вы могли бы сделать что-то с большим количеством cutting и grepping и tkdiff, но вы можете использовать один sedскрипт для выполнения этой работы:
sed -n -e '3{:a' -e 'n;s/.* \([^|]*\)| *[0-9]*| *\([A-Z]*\).*/\1 \2/;H;ta}
G;s/^|[^|]*| *\([^|]*\)| *[0-9]*| *\([A-Z]*\).*\1 \([A-Z]*\).*/\1 New: \2 Old: \3/p' tests.new tests.old
Первая строка собирает новые результаты теста в области хранения, вторая строка сканирует строки старых тестов, сравнивает имя теста с именами в области хранения и печатает строку для совпадения.
Подробное объяснение этого принципа см. в этом ответе .
Обратите внимание, что для больших файлов новых тестов этот скрипт может работать медленно из-за регулярного выражения с обратной ссылкой.
Проблема оказалась связана со сжатием ZFS. У рассматриваемого клиента в его контейнере был запущен зомби-процесс vim, который непрерывно записывал повторяющиеся данные в файл swp.
Сжатие ZFS действительно работает! Как оказалось, потребляемое логическое пространство составляло около 2,4 ТБ, а с впечатляющим коэффициентом сжатия 1700x ZFS уменьшила его до 1,7 ГБ физического.
Статью, в которой точно описывается проблема, см.:
https://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSCompressionAndQuotas
Сейчас мы также рассматриваем возможность отключения сжатия zfs, так как это открывает путь для потенциальной DOS-атаки на нас из-за того, как мы устроены (хотя это очень медленная и малопонятная атака, требующая от нас не платить. внимание ).