Почему мои файловые системы XFS внезапно занимают больше места и полны разреженных файлов?


62

Я использую файловые системы XFS в качестве разделов данных / роста в течение почти 10 лет на различных серверах Linux.

Я заметил странное явление в недавних серверах CentOS / RHEL с версией 6.2+.

Стабильное использование файловой системы стало очень изменчивым после перехода на новую версию ОС от EL6.0 и EL6.1. Системы, изначально установленные с EL6.2 +, демонстрируют то же поведение; показаны дикие колебания в использовании диска на разделах XFS (см. синюю линию на графике ниже).

До и после. Обновление с 6.1 до 6.2 произошло в субботу. график xfs

График использования диска в той же системе за последний квартал, показывающий колебания за последнюю неделю введите описание изображения здесь

Я начал проверять файловые системы на наличие больших файлов и процессов запуска (файлы журнала, может быть?). Я обнаружил, что мои самые большие файлы сообщают разные значения от duи ls. Работа duс --apparent-sizeпереключателем и без него иллюстрирует разницу.

# du -skh SOD0005.TXT
29G     SOD0005.TXT

# du -skh --apparent-size SOD0005.TXT
21G     SOD0005.TXT

Быстрая проверка с использованием утилиты ncdu по всей файловой системе дала:

Total disk usage: 436.8GiB  Apparent size: 365.2GiB  Items: 863258

Файловая система полна разреженных файлов с почти 70 ГБ потерянного пространства по сравнению с предыдущей версией ОС / ядра!

Я просмотрел Red Hat Bugzilla и изменил журналы, чтобы посмотреть, есть ли какие-либо сообщения о том же поведении или новые объявления, касающиеся XFS.

Нада.

Я перешел с версии ядра 2.6.32-131.17.1.el6 на 2.6.32-220.23.1.el6 во время обновления; без изменений в младшем номере версии.

Я проверил фрагментацию файла с помощью filefragинструмента. Некоторые из самых больших файлов в разделе XFS имели тысячи экстентов. Работа в режиме онлайн-дефрагментации xfs_fsr -vв течение медленного периода активности помогла временно сократить использование диска (см. Среду на первом графике выше). Однако использование возобновилось, как только возобновилась активная работа системы.

Что здесь происходит?


2
Ммм ... Пьяцца ....
Том О'Коннор

Ответы:


76

Я проследил эту проблему до обсуждения фиксации в дереве исходного кода XFS с декабря 2010 года. Патч был введен в ядре 2.6.38 (и, очевидно, позже был перенесен в некоторые популярные дистрибутивные ядра Linux).

Наблюдаемые колебания в использовании диска являются результатом новой функции; XFS Dynamic Specutive EOF Preallocation .

Это шаг к уменьшению фрагментации файлов во время потоковой записи за счет умозрительного распределения пространства по мере увеличения размеров файлов. Объем пространства, предварительно выделенный на файл, является динамическим и в основном зависит от свободного пространства, доступного в файловой системе (чтобы полностью исключить нехватку пространства).

Это следует за этим графиком:

freespace       max prealloc size
  >5%             full extent (8GB)
  4-5%             2GB (8GB >> 2)
  3-4%             1GB (8GB >> 3)
  2-3%           512MB (8GB >> 4)
  1-2%           256MB (8GB >> 5)
  <1%            128MB (8GB >> 6)

Это интересное дополнение к файловой системе, поскольку оно может помочь с некоторыми из сильно фрагментированных файлов, с которыми я имею дело.

Дополнительное пространство может быть временно восстановлено путем освобождения кэша страниц, дентриев и инодов с помощью:

sync; echo 3 > /proc/sys/vm/drop_caches

Эта функция может быть полностью отключена путем определения allocsizeзначения во время монтирования файловой системы. По умолчанию для XFS - allocsize=64k.

Влияние этого изменения, вероятно, будет ощущаться системами мониторинга / порогового управления (как я его и обнаружил), но оно также затронуло системы баз данных и могло привести к непредсказуемым или нежелательным результатам для виртуальных машин с тонким предоставлением и массивов хранения (они будут использовать больше места, чем вы ожидаете).

В общем, это застало меня врасплох, потому что не было четкого объявления об изменении файловой системы на уровне распространения или даже при мониторинге списка рассылки XFS .


Изменить :
Производительность на томах XFS с этой функцией значительно улучшена. Я наблюдаю постоянную <1% фрагментацию на томах, которые ранее отображали до 50% фрагментации. Производительность записи повысилась во всем мире!

Статистика из того же набора данных, сравнивая устаревшую XFS с версией в EL6.3.

Старый:

# xfs_db -r -c frag /dev/cciss/c0d0p9
actual 1874760, ideal 1256876, fragmentation factor 32.96%

Новое:

# xfs_db -r -c frag /dev/sdb1
actual 1201423, ideal 1190967, fragmentation factor 0.87%

4
Миллион голосов против тебя и моего королевства
Джоэл Э Салас

1
Спасибо! Мы только что обновились с Debian Squeeze до Ubuntu и задались вопросом, почему du и ls показывают такие сильно отличающиеся значения для больших файлов (например, 50 МБ против 64 МБ)
Giles Thomas

1
@ewwhite Вы отключили эту функцию, чтобы освободить место? Или эта статья просто говорит, эй, эта особенность является причиной расхождений в сообщаемых размерах? Это звучит как «в системах баз данных или виртуальных машинах с тонким предоставлением, подумайте об отключении», но я не уверен, что вы в итоге решили сделать.
JDS

2
@jds Я оставляю это включенным. Это устраняет фрагментацию и повышает производительность моих приложений.
Ewwhite

3
О, чудесная находка. Это использовало 750 ГБ на 35 ГБ файлов. После того, как xfs_fsrон вернулся примерно до 35 ГБ. Я должен следить за этим
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.