ПРЕДУПРЕЖДЕНИЕ: Ошибка файловой системы. Не удалось исправить родительский узел 47322B43. Не удалось найти запись родительского каталога.
У меня установлена ОС Ubuntu 22.04.2 LTS (Jammy Jellyfish), и каждый раз при загрузке появляется следующая ошибка. Я пробовал, но fsck -f /dev/sda2все равно получаю эти ошибки. Пожалуйста, подскажите, как исправить мою систему
решение1
Давайте сначала разберемся, что такое inodes с точки зрения неспециалиста.
Выполняя ... Наша файловая система для этой демонстрации будетЭКСТ2потому что у него нетведение журналамеханизм и, таким образом, его будет легко повредить в целях демонстрации некоторых проблем, связанных с inode.
Давайте создадим файл образа «диска»:
$ truncate -s 10M myfilesystem
И отформатируйте его.
$ mkfs.ext2 myfilesystem
mke2fs 1.46.5 (30-Dec-2021)
Discarding device blocks: done
Creating filesystem with 2560 4k blocks and 2560 inodes
Allocating group tables: done
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
Обратите внимание на количество инодов ... and 2560 inodes... Это постоянное максимальное количество для этой файловой системы на этом разделе диска... Вы можете создать столько файлов(все виды, включая каталоги) как это число(за исключением специальных инодов файловой системы), но не более указанного числа в данной файловой системе.
Давайте создадим точку монтирования и смонтируем эту файловую систему:
$ mkdir mymount
$
$ mount myfilesystem mymount/
$
$ ls -la mymount/
total 24
drwxr-xr-x 3 root root 4096 May 8 14:24 .
drwxr-xr-x 3 ubuntu ubuntu 4096 May 8 14:29 ..
drwx------ 2 root root 16384 May 8 14:24 lost+found
$
$ df -ih mymount/
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/loop1 2.5K 11 2.5K 1% /home/ubuntu/test/mymount
Обратите внимание на количество используемых инодов 11... Они называются специальными инодами и зарезервированы/используются по умолчанию для специальных предопределенных целей файловой системы... Давайте используем еще некоторые из них:
$ touch mymount/file{1..2}
$
$ ls -lai mymount/
total 24
2 drwxr-xr-x 3 root root 4096 May 8 14:33 .
2552 drwxr-xr-x 3 ubuntu ubuntu 4096 May 8 14:29 ..
12 -rw-r--r-- 1 root root 0 May 8 14:33 file1
13 -rw-r--r-- 1 root root 0 May 8 14:33 file2
11 drwx------ 2 root root 16384 May 8 14:24 lost+found
$
$ df -ih mymount/
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/loop1 2.5K 13 2.5K 1% /home/ubuntu/test/mymount
Мы создали два файла и использовали еще два инода и в итоге получили 11 + 2 = 13.
Давайте освободим одного из них:
$ rm mymount/file1
$
$ df -ih mymount/
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/loop1 2.5K 12 2.5K 1% /home/ubuntu/test/mymount
Это обычные 13 - 1 = 12используемые иноды, и тот, который мы только что освободили, будет использован повторно при необходимости... иноды подлежат вторичной переработке.
Это в нормальных условиях... Но что, если мыв другой оболочкепостоянно открывать и использовать файл:
$ tail -f mymount/file2
-
Затем вернитесь в нашу исходную оболочку, чтобы удалить этот файл, а затем немедленно некорректно размонтируйте файловую систему:
$ rm mymount/file2 && umount -l myfilesystem
$
$ ls -lai mymount/
total 8
6425 drwxr-xr-x 2 root root 4096 May 8 14:29 .
2552 drwxr-xr-x 3 ubuntu ubuntu 4096 May 8 14:29 ..
Затем смонтируйте его снова:
$ mount myfilesystem mymount/
$
$ ls -lai mymount/
total 24
2 drwxr-xr-x 3 root root 4096 May 8 14:44 .
2552 drwxr-xr-x 3 ubuntu ubuntu 4096 May 8 14:29 ..
11 drwx------ 2 root root 16384 May 8 14:24 lost+found
$
$ df -ih mymount/
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/loop1 2.5K 12 2.5K 1% /home/ubuntu/test/mymount
Обратите внимание, что хотя файл фактически удален, его inode не освобожден... Это «симуляция» повреждения файловой системы... Давайте размонтируем и проверим:
$ umount myfilesystem
$
$ e2fsck myfilesystem
e2fsck 1.46.5 (30-Dec-2021)
myfilesystem was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Deleted inode 13 has zero dtime. Fix<y>? yes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Inode bitmap differences: -13
Fix<y>? yes
Free inodes count wrong for group #0 (2548, counted=2549).
Fix<y>? yes
myfilesystem: ***** FILE SYSTEM WAS MODIFIED *****
myfilesystem: 11/2560 files (0.0% non-contiguous), 170/2560 blocks
Давайте закроем другую оболочку, снова смонтируем и проверим:
$ mount myfilesystem mymount/
$
$ df -ih mymount/
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/loop1 2.5K 11 2.5K 1% /home/ubuntu/test/mymount
Теперь вы знаете основы использования inodes... И некоторые из того, что может пойти не так с ними, чтобы вызвать проверку файловой системы, и как... То же самое может произойти при подключении/отключении диска или при внезапном отключении питания системы, когда файлы(особенно системные файлы) постоянно создаются/удаляются/обновляются системными процессами... В случае с каталогами ситуация немного хуже, поскольку обычно процесс не может держать каталог открытым, поскольку у них нет дескриптора, как у обычных файлов, но повреждение может произойти с inode каталога, если вышеуказанное произошло во время обновления/изменения их метаданных, а также, хотя и редко, это может произойти, когда файловая система теряет доступ к определенным блокам из-за отказа/износа жесткого диска.
Однако большинство проблем с inode можно легко автоматически устранить с помощью утилит проверки файловой системы.
Вернемся к вашему вопросу
Однако бывают случаи, когда эти утилиты теряются и не знают, как исправить проблему с inode, особенно с каталогами, которые не имеют допустимых читаемых метаданных, поскольку среди методов, которые эти утилиты используют для исправления повреждений inode, на самом деле есть метаданные, которые идентифицируют содержимое каталогов, родительские элементы и т. д.
Скриншот, который вы приложили, немного затрудняет для меня чтение и копирование текста из ... Однако, похоже, у вас есть inode 4732284(под/usr/src/linux ... /net/ ...), который помечен как каталог в файловой системе, но не имеет обычных метаданных, описывающих его связь с родительскими файлами, что делает его бесхозным и не занимает обычное пространство в один блок, например, 4kа скорее занимает 0пространство и, следовательно, NULL... В то время как в большинстве файловых систем файлы могут иметь размер null/0, каталоги не могут, см.эта почтаиэта почтаБольше подробностей.
Этот тип проблем,если он не увеличивается резко, это может указывать на неисправный диск/плохие и изношенные блоки, не является большой проблемой и не должно быть опасным... Чтобы избавиться от него простым способом, вам просто нужно его использовать... т. е. создать файл в этом каталоге, затем удалить его, чтобы обновить его метаинформацию, чтобы он вернулся к использованию полного размера блока файловой системы и выглядел более-менее нормально... Этот каталог должно быть легко обнаружить, поскольку он будет показывать 0размер в выводе, например, ls -laи после того, как вы его используете, он должен показывать обычный размер блока, например, 4kкак и другие каталоги в той же файловой системе... Если этого недостаточно, чтобы вернуть его в нормальное состояние, то встряхните его еще раз, например, установив его владельца, например, chown root:rootили изменив его разрешения, например, chmod 755пока не ls -laпокажет какой-то размер, отличный от размера 0для этого каталога.
Затем отмонтируйте содержащуюся в ней файловую систему и снова запустите утилиту проверки файловой системы, и на этот раз она должна исправить проблему.
Это должно сработать, но если не сработало, то у вас есть две альтернативы...Илис помощью отладчика файловой системы, напримерdebugfsчтобы вручную исправить/удалить запись этого inodeилив качестве альтернативы выполните резервное копирование данных и переформатируйте раздел диска.