Что случилось с сообщением об ошибке "Очистка структуры"
Ошибка "структура нуждается в очистке" - это ошибка, которую файловые системы (в частности, 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 . Если у вас есть файл с несколькими жесткими ссылками, пробел освобождается только после удаления последней жесткой ссылки. Если у вас есть несколько активных пространств имен, каждое пространство имен фактически действует как "жесткая ссылка" на рассматриваемое монтирование. Поэтому простое размонтирование файловой системы в пространстве имен монтирования по умолчанию не поможет, если какой-то процесс разветвит пространство имен монтирования по умолчанию и работает сам, и, возможно, некоторые дочерние процессы в этой копии копируют при записи своего родительского пространства монтирования.
