42TB LUN, отформатированный в XFS и переданный через NFS, был отмечен клиентами как «недоступный». В конце концов я был вынужден перезапустить файловый сервер. LUN XFS не будет монтироваться, пока он не будет отремонтирован, и для ремонта мне нужно смонтировать его, чтобы журнал воспроизвел и зафиксировал незафиксированные изменения. Раньше я узнал, что сброс журнала и запуск восстановления приводит к потере имен файлов для части файлов и папок в LUN. 42 ТБ и потенциально сотни тысяч файлов. Потеря имен файлов приравнивается к потере данных.
У меня есть резервная копия. Восстановление потребует сбора ресурсов. Я думаю, что в этом LUN есть примерно 30 ТБ данных, которые мне нужно восстановить и скопировать на место. Итак, мне нужно 30 ТБ свободного места, чего нет в наличии.
Есть ли другой способ заставить XFS монтироваться, чтобы воспроизвести эти журналы и зафиксировать изменения?
Это уже третий раз, когда у меня LUN «зависает», и я сообщаю, что xfs поврежден в журналах и был вынужден перезагрузить сервер, чтобы вернуть его в оперативный режим. У XFS, кажется, солидная репутация. Он существует уже довольно давно. И это значение по умолчанию для ОС файлового сервера (RHEL7). У меня какая-то ужасная ошибка в моей конфигурации, которая убивает эти LUN?
SAN представляет LUN, смонтированный nodev, nosuid, nofail на файловом сервере. Совместное использование файлового сервера с рабочими станциями, которые монтируют общий ресурс как синхронный. Есть ли в этой комбинации что-то, что могло бы повесить файловый сервер?
Столкнулся с этим вопросом при проверке обновлений ошибок # 1681410 и # 1686687 на панели запуска, на которую меня также повлияли симптомы, похожие на описываемые вами (также с XFS, но с большим LUN и при запуске сервера ubuntu 16.04).
Мы довольно глубоко проверяли нашу систему хранения (которая предоставляет обширные журналы) (запрашивая поддержку у производителя), но в итоге не обнаружили там никаких ошибок или неправильных настроек.
Столкнувшись с этим несколько раз, нам удалось свести возникновение такого поведения к определенному моменту, когда никто не мог активно работать над системой, что позволило нам рассмотреть и другие факторы. Наконец, мы нашли доказательства того, что запуск fstrim по расписанию cron (который по умолчанию на сервере ubtuntu 16.04!), Запускаемый один раз в неделю, по-видимому, вызывает повреждения в нашей файловой системе, особенно потому, что требуется некоторое время для fstrim LUN размером более 100 ТБ. .
Я считаю, что ошибки, опубликованные на панели запуска, скорее всего, описывают эту проблему, но, как мне кажется, эта проблема была обновлена, но до сих пор так и не исправлена. Итак, пока мы просто убеждаемся, что fstrim не запущен, удалив соответствующую форму записи cron.weekly. Мы также проверяем, было ли повторно добавлено задание cron после запуска обновлений, что я бы хотел решить по-другому.