В рассматриваемой системе установлен Debian Lenny с ядром 2.6.27.38. Система имеет 16 ГБ памяти и 8 дисков по 1 ТБ, работающих за картой RAID 3Ware.
Хранилище управляется через LVM и состоит исключительно из файловых систем ext3.
Укороченная версия:
Мы хорошо знакомы с LVM и KVM, поэтому решили, что это будет безболезненная операция:
Гость загрузился успешно, и запуск "df" показал лишнее пространство, однако через некоторое время система решила перемонтировать файловую систему в режиме только для чтения без явного указания на ошибку.
Будучи параноиками, мы выключили гостя и снова запустили проверку файловой системы, учитывая новый размер файловой системы, мы ожидали, что это займет некоторое время, однако теперь он работает более 24 часов, и нет никаких указаний на то, сколько времени это займет. .
Используя strace, я вижу, что fsck «делает что-то», аналогично запускает «vmstat 1». Я вижу, что происходит много операций ввода / вывода блоков.
Итак, теперь у меня тройной вопрос:
Кто-нибудь сталкивался с подобной ситуацией? Обычно мы делали такое изменение размера в прошлом без каких-либо проблем.
Какая наиболее вероятная причина? (Карта 3Ware показывает, что RAID-массивы резервных хранилищ в порядке, хост-система не перезагружалась, и ничего в dmesg не выглядит важным / необычным)
Игнорирование btrfs + ext3 (недостаточно зрелого, чтобы доверять), должны ли мы в будущем создавать наши большие разделы в другой файловой системе, чтобы избежать этого повреждения (независимо от причины) или уменьшить время fsck? xfs кажется очевидным кандидатом?
Похоже, что у томов больше 1Тб проблемы с virtio:
https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/574665
http://kerneltrap.org/mailarchive/linux-kvm/2010/4/23/6261185/thread
http://sourceforge.net/tracker/index.php?func=detail&aid=2933400&group_id=180599&atid=893831
Также проверьте настройки кэша KVM; KVM не может выполнять кэширование, кэш чтения, обратную запись и сквозное кеширование, что может вас удивить.
В этом случае, вероятно, это проблема virtio и 1 ТБ.
Но для меня я столкнулся с аналогичными проблемами при попеременном доступе к устройству вне виртуальной машины (включая выключение этой машины) и внутри виртуальной машины. Если вы получаете доступ к блочному устройству внутри виртуальной машины с прямым доступом (например, в конфигурации kvm), это означает, что без кеша / буферов и снаружи с буферами вы можете получить следующую проблему:
При изменении размера устройства за пределами виртуальной машины кеш / буферы заполняются на узле kvm.
запускаем vm, распознаем (другие!) проблемы и завершаем работу.
устройство fsck.
Если все пошло очень плохо, вы читаете дату из кеша, но это было изменено в ранее запущенной виртуальной машине, которая обращалась к устройству без буферов / кеша!
Я также часто меняю размеры ext3 (начиная с версии 2.6.18), и я делаю это все время ОНЛАЙН! AFAIK это использует функции ядра для изменения размера, в то время как автономное изменение размера использует код пользовательского пространства.