Речь идет о файловой системе ext4 на логическом томе, управляемом с помощью LVM на LUKS-шифровании на аппаратном RAID. Операционная система — обычная Ubuntu 22.04 LTS.
К сожалению, RAID недавно вышел из строя, и файловая система была переназначена только для чтения в то время. После остановки всех приложений, пишущих в эту файловую систему, RAID можно было полностью восстановить, если повезет. И, если повезет еще больше, файловая система все еще полностью читаема с восстановленными данными! И e2fsckдаже не было обнаружено ошибок.
Так все в порядке? К сожалению, нет. К сожалению, в памяти все еще скопилось довольно много (сотни мегабайт) незаписанных данных, и я не знаю, как вытащить их на диск. Вот почему я еще не перезагрузился, и вот почему я не хочу перезагружать, потому что восстановление всех файлов базы данных с этими отсутствующими данными будет большой работой. Наличие незаписанных данных можно легко проверить с помощью:
sync ; grep Dirty /proc/meminfo
что обычно дает всего несколько килобайт, но в моем случае дает сотни мегабайт. К сожалению, я не знаю, на каком уровне различных драйверов ядра находятся эти данные: кэш физического диска, одна из групп томов или фактическая файловая система.
Ремонты, которые были предприняты до сих пор
Моей первой попыткой было перемонтировать файловую систему, которая по-прежнему доступна только для чтения, как доступную для чтения и записи с помощью:
mount -o remount /dev/mapper/vg1-data
К сожалению, это приводит к сообщению об ошибке:
mount: /data: cannot remount /dev/mapper/vg1-data read-write, is write-protected.
Однако фактический объем доступен для чтения и записи, что можно проверить с помощью:
cat /sys/block/dm-*/ro
что дает результат 0для всего, что находится под контролем устройства сопоставления, включая тома на вершине RAID. То же самое верно и для самого sdустройства. Более того:
dmsetup info vg1-data
сообщает о состоянии тома как ACTIVE. Вместо этого он сообщил бы о состоянии как ACTIVE (READ-ONLY), если бы он был доступен только для чтения. Аналогично, lvsпоказывает обычные атрибуты -wi-ao----.
Большая подсказка, что возможность чтения-записи файловой системы на самом деле НЕ является источником проблемы, можно узнать через tune2fs -l. Это выводит, среди многих других статистических данных, эту информацию о последней ошибке в смонтированной файловой системе:
Last error time: Wed Jan 17 18:47:43 2024
Last error function: ext4_remount
Last error line #: 5822
Last error err: EBUSY
В момент возникновения этой ошибки в системном журнале появляется следующая загадочная строка:
EXT4-fs error (device dm-N): ext4_remount:5822: comm mount: Abort forced by user
Когда я явно принудительно переводю том в режим «только чтение» с помощью:
dmsetup table vg1-data | dmsetup reload -r vg1-data
dmsetup resume vg1-data
dmsetup info vg1-data
затем дальнейшие повторные mountпопытки больше не обновляют эту временную метку "Last error time", но выдают то же самое (и теперь, очевидно, правильное) сообщение об ошибке. После того, как я dmsetupснова использовал , чтобы сделать том чтением-записью, дальнейшие повторные mountпопытки снова обновят временную метку Last error, а также снова запишут в syslog.
В другом сообщении о сбое сервера я нашел подсказку о том, как установить тома Disk Mapper в режим «только чтение», а затем обратно в режим «чтение и запись», но это тоже не помогло:Программный RAID 1 для Linux — корневая файловая система становится доступной только для чтения после сбоя на одном диске
cryptsetup reloadтакже ничего не добились.