Linux временно думает, что диск заполнен

Question

Я работаю на сервере Linux с CentOS 6.5 и NFS NAS в сети QDR Infiniband. Я бегу bash скрипт , который в основном создает каталог, делает символические ссылки внутри него, и cat S вместе один небольшой файл в каждом каталоге. Это делается для нескольких сотен каталогов.

В выходном журнале я заметил, что не удалось запустить одну из символических ссылок и последующую команду cat , заявив, что диск заполнен. Это было совершенно ясно, нет. Запустив этот же скрипт для нескольких тысяч каталогов, я начал получать очень большое количество этих сообщений. Я проверил, и диск выглядел переполненным, поэтому я немедленно убил свой сценарий, но через несколько минут диск вернулся в нормальное состояние.

Вот последовательные команды df которые я видел: первая во время работы скрипта, вторая сразу после его уничтожения и третья несколько секунд спустя /home3(NAS) - это та, над которой я работаю:

[swfl 07:40:56 JPM]$ df -h
Filesystem                       Size  Used Avail Use% Mounted on
/dev/mapper/vg_misisss6-lv_root  135G   25G  104G  19% /
tmpfs                             12G     0   12G   0% /dev/shm
/dev/sda1                        485M   69M  392M  15% /boot
misisss-nasib3:/home              26T   26T  1.0M 100% /home3
misisss-nas1:/shared              77G  437M   73G   1% /shared
misisss-nasib2:/home              15T   15T   95G 100% /home2
You have new mail in /var/spool/mail/swfl

[swfl 07:41:39 JPM]$ df -h
Filesystem                       Size  Used Avail Use% Mounted on
/dev/mapper/vg_misisss6-lv_root  135G   25G  104G  19% /
tmpfs                             12G     0   12G   0% /dev/shm
/dev/sda1                        485M   69M  392M  15% /boot
misisss-nasib3:/home              26T   26T  1.0M 100% /home3
misisss-nas1:/shared              77G  437M   73G   1% /shared
misisss-nasib2:/home              15T   15T   94G 100% /home2

[swfl 07:41:58 JPM]$ df -h
Filesystem                       Size  Used Avail Use% Mounted on
/dev/mapper/vg_misisss6-lv_root  135G   25G  104G  19% /
tmpfs                             12G     0   12G   0% /dev/shm
/dev/sda1                        485M   69M  392M  15% /boot
misisss-nasib3:/home              26T   21T  4.2T  84% /home3
misisss-nas1:/shared              77G  437M   73G   1% /shared
misisss-nasib2:/home              15T   15T   93G 100% /home2

В то время загрузка большинства ядер была относительно небольшой, а использование дисков от низкого до умеренного. У меня не запущено программное обеспечение для мониторинга, поэтому я не могу дать цифры IOps или что-то в этом роде, но я проделал работу, похожую на эту, но с гораздо более высокой интенсивностью без проблем.

Короче говоря, было бы очень трудно поверить, что я подавлял какую-то часть системы выполняемой работой. Хлебные крошки, где искать проблемы?

ОБНОВЛЕНИЕ 1 Запуск watch 'df -h; df -i' для отслеживания inode и использования диска, я вижу резкое падение дискового пространства (все в порядке ~ 5 секунд, затем несколько TB исчезают в течение 10-20 секунд), пока я не начну получать ошибки, но в од не падает почти так же.

Я могу видеть, что оды имеют довольно высокий коэффициент использования (30-70%). У меня ~ 16 миллиардов инодов, и я создаю ~ 40000 файлов / каталогов. После того, как я завершу процесс, дисковое пространство начнет медленно расти (несколько ГБ) в течение 10-20 секунд, а затем отскочит обратно на несколько ТБ до первоначального уровня.

Answer 1

Заметив, что дисковое пространство высвободилось за 5-минутный цикл, мы смогли выявить проблему. Такое поведение может быть уникальным для файловой системы, которую мы используем, для файловой системы XFS.

XFS позволяет указать заранее выделенный размер файла. Мы смонтировали файловую систему с allocsize=1G , учитывая, что эта файловая система была построена с учетом больших файлов, и мы хотели избежать фрагментации. Вы также можете указать частоту обновления для файловой системы, чтобы затем возвращаться и пересматривать использование из предварительно распределенных значений. Значение по умолчанию 5 минут было тем, почему мы видели это циклическое поведение. Некоторая связанная информация об этом поведении может быть найдена здесь.

Итак, когда я создал файл, а затем выполнил для него команду cat , этого второго действия над файлом было достаточно, чтобы система начала предварительно выделять 1 ГБ для этого файла. Таким образом, зацикливание нескольких тысяч таких файлов на очень высокой скорости привело к тому, что все дисковое пространство оказалось исчерпанным, прежде чем модуль хранения смог отрегулировать эти выделения.

Мы удалили эту опцию монтирования, чтобы позволить файловой системе идти с динамическим предварительным размещением, что более разумно в отношении меньших файлов и доступной емкости файловой системы.