Примечание: Это вопрос «документирования моего процесса», на который я напишу ответ. К счастью, serverfault уже помог мне решить эту проблему, потому что запись моей ситуации, чтобы другие могли ее оценить, заставила меня понять, что происходит.
kjournald (видно через iotop).noatime,nodiratime.Что происходит? (Спойлеры: это было связано с пользовательским пространством. Я пишу это в основном, чтобы выделить, возможно, противоречащие интуиции основные проблемы.)
Посмотрите, что произошло: основное приложение, работающее на этом сервере, управляет чрезвычайно большим, хорошо заполненным деревом каталогов и записывает файлы в это дерево с несколько неоптимальным владением и разрешениями. Поскольку довольно неприятно заставить это приложение изменить это, а файлы нуждаются в том, чтобы их права собственности и разрешения были исправлены достаточно быстро (небольшая задержка - это нормально, но не много), я настроил задание cron, чтобы каждую минуту бросать массу chown -R и chmod -R в большом, хорошо заполненном дереве каталогов. Казалось, что все работает нормально, пока это происходит, поэтому я сказал: ну, это перебор, но работает, я с этим переживу.
Тем не мение. Оказывается, когда вы делаете chown или chmod, он регистрирует журналируемые метаданные файловой системы ext независимо от того, имело ли место какое-либо изменение. Итак, в файловой системе ничего или почти ничего не менялось, но необъятный были сгенерированы объемы метаданных, которые затем вылетели из диска, когда журнал зафиксировал. Ой.
Так что я изменил chown и chmod к find задания, которые фактически ищут файлы, которые необходимо изменить перед их изменением, и средняя скорость записи увеличилась с 2 МБ / с до 50 кБ / с. Ура.