Ubuntu Server: невозможно удалить файл "x", структура нуждается в очистке

Что случилось с сообщением об ошибке "Очистка структуры"

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