Назад | Перейти на главную страницу

Риск не исправления ошибок XFS «Требуется очистка конструкции»

У меня файловая система XFS с ошибками файловой системы, влияющими на некоторые некритические файлы. Я хочу его отремонтировать; бизнес желает и дальше работать с этими ошибками. Каковы известные риски неиспользования восстановления файловой системы XFS, содержащей ошибки «Структура требует очистки»?

Компания хочет избежать возможного длительного периода обслуживания, который может потребоваться. Я всегда считал, что с повреждением файловой системы нельзя мириться. Компания будет спрашивать меня о причинах, кроме моего собственного FUD.

Какие ответы нужны

У меня уже есть мнение; Мне нужно больше, чем это.

Ответы должны быть подкреплены доказательствами (анекдоты допустимы, но только если они задокументированы из первых рук. Нам не нужны ответы «кто-то сказал мне»). Эксперт мнения в порядке, например, ответ из FAQ XFS или от разработчика, знакомого с внутренним устройством XFS).

Никаких непрофессиональных мнений, пожалуйста. Я ищу доказательства, достоверный анекдот и XFS эксперт мнение.

Отрицательные ответы (например, «при аналогичных обстоятельствах я бегал год и не испытывал серьезных проблем) - допустимы.

Детали файловой системы.

Размер файловой системы составляет 5,4 ТБ, используется 3,9 ТБ (72%).

Есть 46,6M файлов.

Детали ошибки

Есть 55 поврежденных каталогов, которые вызывают такие приложения, как ls и find чтобы сообщить "Структура нуждается в очистке", как указано в эта запись XFS FAQ:

В: Я вижу, что приложения возвращают ошибку 990 или «Требуется очистка структуры», что не так?

Ошибка 990 означает EFSCORRUPTED, что обычно означает, что XFS обнаружила проблему с метаданными файловой системы и отключила файловую систему, чтобы предотвратить дальнейшее повреждение. Кроме того, примерно с июня 2006 года мы перешли с EFSCORRUPTED / 990 на использование EUCLEAN, «Структура нуждается в очистке». К сожалению, причиной может быть что угодно - файловая система, диспетчер виртуальной памяти, диспетчер томов, драйвер устройства или оборудование. Когда это происходит изначально, должно появиться подробное консольное сообщение. Сообщения содержат важную информацию, дающую разработчикам подсказку относительно самой ранней точки обнаружения проблемы. Он нужен для защиты ваших данных. Вы можете использовать xfs_repair для устранения проблемы (с отключенной файловой системой).

Ошибки XFS регистрируются в syslog все выглядят так:

XFS (sdb): Metadata corruption detected at xfs_inode_buf_verify+0x6d/0xe0 [xfs], block 0x50
XFS (sdb): Unmount and run xfs_repair
XFS (sdb): First 64 bytes of corrupted metadata buffer:
ffff88073fa79000: 49 4e 41 ff 02 01 00 00 00 00 01 f6 00 00 01 f7  INA.............
ffff88073fa79010: 00 00 00 04 00 00 00 00 00 00 00 00 00 00 00 ed  ................
ffff88073fa79020: 59 1b af d2 09 62 5c 17 4f e8 f8 73 00 00 00 00  Y....b\.O..s....
ffff88073fa79030: 57 e0 73 b2 27 23 63 cd 00 00 00 00 00 00 00 2f  W.s.'#c......../
XFS (sdb): metadata I/O error: block 0x50 ("xfs_trans_read_buf_map") error 117 numblks 16
XFS (sdb): xfs_imap_to_bp: xfs_trans_read_buf() returned error 117.

Эти ошибки повторяются много раз, но только для двух блоков.

Вам следует восстановить файловую систему, поскольку это может указывать на основную проблему с массивом хранения или оборудованием.

Найдите время на простои или техническое обслуживание ... или сделайте так, чтобы резервирование было лучше.

На этом этапе я бы проверил состояние оборудования.


Предполагая, что вы используете корпоративную ОС Linux (а не Arch Linux), доступно творческое решение. Вы можете использовать любую текущую версию Утилита / драйвер Linux HotCopy is и сделайте снимок вашей файловой системы на уровне блоков. Смонтируйте эту файловую систему примерно так:

mount -t xfs -o nouuid,norecovery /dev/hcp1 /some-mountpoint

Оттуда вы можете бежать и xfsrepair на снимке, чтобы оценить серьезность проблемы, список проблем и в качестве временного теста.

Размонтируйте и уничтожьте снимок после завершения.

Файловую систему действительно нужно отключить и проверить / отремонтировать, по крайней мере, по двум очень веским причинам:

  • ошибка метаданных в каталогах в основном блокирует их из-под вашего контроля. Ты не можешь ls их, или создавать / удалять файлы внутри них.
  • ошибка метаданных может вызвать отказоустойчивый механизм XFS - отключение файловой системы. Если это произойдет, ваш клиент воля принять внеплановый время простоя, может быть, в наихудший момент когда-либо. Намного лучше планировать время простоя в тихие часы (например, в ночное время).

Некоторые предложения:

  • перед запуском полномасштабного xfs_repair, вы можете выгрузить все метаданные файловой системы, используя xfs_metadump и запустить "пустышку" xfs_repair на них. Это даст вам возможность наблюдать, что xfs_repair будет делать с / в вашей файловой системе
  • быть конечно иметь действительные и недавние резервные копии перед любой попыткой ремонта
  • если ты действительно действительно, действительно не может вывести файловую систему из строя и если файлы, содержащиеся в проблемных каталогах, не имеют / не имеют большого значения, вы можете попробовать удалить сами каталоги. Это эффективно «отключит» проблемную область метаданных. Обязательно поймите, что это только (плохой) обходной путь; более того, если удаление завершится неудачно, XFS, вероятно, отключит всю файловую систему, вынудив вас провести незапланированный простой.