Нормально ли это при удалении снимка btrfs?
У меня есть несколько компьютеров под управлением Debian 8, dovecot и btrfs. Я использую моментальные снимки btrfs для краткосрочного резервного копирования. Для этого я храню 14 снимков подобома почты.
Производительность в порядке, пока не дойдет до удаления снимка: как только срабатывает btrfs-cleaner, все почти останавливается. Это приводит к тому, что drbd теряет подключение к вторичному узлу из-за тайм-аута. Это происходит на нескольких устройствах, поэтому вряд ли проблема связана с оборудованием.
Spike - это место, где происходит удаление снимка: 
Не могу поверить, что это нормальное поведение. Итак, мой вопрос: есть ли у кого-нибудь опыт работы с этой проблемой, есть ли идеи о том, как ее решить или отладить, или, в крайнем случае, как ее избежать, действуя по-другому?
Системы: Dell R710, Debian 8, Kernel 3.16, варианты монтирования: rw, noatime, nossd, space_cache
Изменить: дополнительная информация о системе
Двойной R710, 24 ГБ ОЗУ, H700 с кешем записи, 8x1 ТБ 7.2k Sata-дисков в качестве RAID6, протокол DRBD B, выделенный канал 1 ГБ / с для DRBD
Изменить: удаление содержимого снимка с помощью rm -rf. Задросселирован для ввода-вывода, иначе он бы убежал, как это сделал btrfs-cleaner:
Я бы сделал вывод, что это намного хуже с точки зрения io. Единственное преимущество заключается в том, что я могу контролировать нагрузку ввода-вывода пользовательского пространства rm.
И еще одно изменение: резня в Иопсе
В мире CoW (в основном BTRFS и ZFS) удаление моментального снимка / подобъема требует множества «тяжелых» операций с метаданными, что подразумевает множество поисков головы. Это происходит из-за того, что файловая система анализирует свои собственные структуры, чтобы определить блок, который используется исключительно ошибочным моментальным снимком. Это, в свою очередь, может поставить систему на колени.
Чтобы убедиться, что это проблема, сделайте следующее:
- открыть два терминала с
screen - на первом терминале запустите
iostat -x -k 1 - на втором терминале снимаем снимок
- Во время удаления проверьте первый терминал: вы, вероятно, обнаружите, что ваши диски заняты 100%, читая много-много небольших блоков данных.
Если проблема подтверждается, вы можете попробовать первый удалить содержимое снимка (с помощью простого rm), затем удалить сам снимок.
В качестве примечания: хотя файловые системы CoW чрезвычайно гибки, они не рассчитаны на чистую производительность. И хотя ZFS остается довольно быстрой, то же самое нельзя сказать о BTRFS.
В любом случае, удаление больших субтомов было проблематичным и для ZFS (пока не был реализован процесс удаления в фоновом режиме ...)
Похоже на малоизвестная ошибка в функции квот btrfs.
Просто отключите квоты btrfs следующей командой.
btrfs quota disable /
UPD: нашел подробное анализ проблемы. Это не ошибка, а особенность.