Что случилось с сообщением об ошибке «Очистка структуры»
Ошибка «структура нуждается в очистке» - это ошибка, которую файловые системы (в частности, ext4 и xfs) возвращают при обнаружении проблемы повреждения файловой системы. К сожалению, единственное, что можно сделать для исправления повреждения, - это размонтировать диск и запустить его e2fsckв файловой системе. (Технически эта -fопция вам не понадобится, поскольку файловая система уже обнаружила проблемы и пометила файловую систему как имеющую проблемы. Поэтому при запуске e2fsckона выполнит полное сканирование, чтобы устранить эти проблемы, и вам не нужно -fвозможность заставить чек.)
Сообщения о повреждении файловой системы
Вы также должны видеть отчеты о повреждении файловой системы, просматривая журналы ядра. (Например, запустив dmesg, или посмотрев, /var/log/kern.logили где-либо ваш syslogили journaldбыл настроен для записи сообщений ядра. Вы должны увидеть сообщения, которые начинаются EXT4-fs error (device sdXX). Например:
EXT4-fs error (device sda3): ext4_lookup:1602: inode #37005: comm docker: deleted inode referenced: 31872136 Вы также можете увидеть признаки ошибок, посмотрев на dumpe2fs -hфайловую систему. Области интересов:
FS Error count: 25 Это означает, что ядро обнаружило несоответствия файловой системы 25 раз.
First error time: Thu Jan 1 12:19:59 2015 First error function: ext4_ext_find_extent First error line #: 400 First error inode #: 95223833 First error block #: 0 Первая ошибка была обнаружена 1 января 2015 года в указанное время. Функция error и строка # позволяют точно определить, какая часть кода ядра обнаружила проблему. Inode # сообщает, какой inode был связан с несоответствием файловой системы.
Last error time: Wed Feb 4 11:57:05 2015 Last error function: ext4_ext_find_extent Last error line #: 400 Last error inode #: 95223833 Last error block #: 0 Это говорит о том, что ядро недавно обнаружило несоответствие файловой системы. Большие различия между двумя значениями означают, что кто-то не сканировал свои сообщения ядра. Это происходит потому, что каждые 24 часа ext4 будет регистрировать предупреждающие сообщения о том, что существует файловая система с повреждениями, и эти сообщения ядра будут выглядеть так:
EXT4-fs (dm-0): error count since last fsck: 12 EXT4-fs (dm-0): initial error at time 1441536566: ext4_dirty_inode:4655 EXT4-fs (dm-0): last error at time 1441537273: ext4_remount:4550 Примечание: время в сообщениях ядра - это количество секунд с 1 января 1970 года до полуночи UTC. Вы можете преобразовать это в более удобочитаемое время, используя команду date, например:
% date -d @1441536566 Sun Sep 6 06:49:26 EDT 2015 Что делать, если вы узнали, что ваша файловая система повреждена
Вы действительно не хотите работать с несоответствиями файловой системы, так как это может привести к большей потере данных. Это действительно хорошая идея, чтобы перейти к этим отчетам, запланировать время простоя, если это необходимо, и исправить их как можно скорее.
Почему вы e2fsckпожаловались, что устройство использовалось после того, как я размонтировал его?
Наконец, в ответ на ваш вопрос: «Я бежал fsckпосле размонтирования, и я получаю следующую ошибку: /dev/sdb1 is in use.Есть идеи?» Вероятно, это связано с тем, что у вас есть один или несколько процессов в альтернативном пространстве имен монтирования, и эти процессы все еще /dev/sdb1монтируются в этом пространстве имен монтирования. Вы можете попробовать:
grep /dev/sdb1 /proc/*/mounts Если вы обнаружите, что процессы выполняются в альтернативном пространстве имен монтирования, самое простое, что нужно сделать - это убить и перезапустить эти процессы. (Вероятно, это процессы-демоны.) Когда завершается последний процесс, использующий пространство имен монтирования, пространство имен монтирования исчезает. И как только не будет больше монтируемых пространств имен /dev/sdb1, оно будет действительно размонтировано по-настоящему.
Способ думать об этом, который umountдействует как unlink. Если у вас есть файл с несколькими жесткими ссылками, пробел освобождается только после удаления последней жесткой ссылки. Если у вас есть несколько активных пространств имен, каждое пространство имен фактически действует как «жесткая ссылка» на рассматриваемое монтирование. Поэтому простое размонтирование файловой системы в пространстве имен монтирования по умолчанию не поможет, если какой-то процесс разветвит пространство имен монтирования по умолчанию и работает сам, и, возможно, некоторые дочерние процессы в этой копии копируют при записи своего родительского пространства монтирования.