fsck показывает ext4 ошибки файловой системы, но только при начальной загрузке от системного раздела
У меня есть проблема с моим ext4 системным разделом. Я работаю 17.04 (обновленный от 16,10), но проблема уже присутствовала в 16,10.
Иногда (обычно после пробуждения системы от приостанавливают), системные катастрофические отказы с набором ext4 ошибок файловой системы.
Теперь при проверке файловой системы с
sudo fsck -n /dev/nvme0n1p2
fsck утверждает, что файловая система является чистой
fsck from util-linux 2.29
e2fsck 1.43.4 (31-Jan-2017)
Warning! /dev/nvme0n1p2 is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
/dev/nvme0n1p2: clean, 434755/15089664 files, 46490132/60347136 blocks
Однако, если я вызываю проверку, я получаю целый набор ошибок:
sudo fsck -nf /dev/nvme0n1p2
fsck from util-linux 2.29
e2fsck 1.43.4 (31-Jan-2017)
Warning! /dev/nvme0n1p2 is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
Pass 1: Checking inodes, blocks, and sizes
Inodes that were part of a corrupted orphan linked list found. Fix? no
Inode 131275 was part of the orphaned inode list. IGNORED.
Inode 135221 was part of the orphaned inode list. IGNORED.
Inode 135244 was part of the orphaned inode list. IGNORED.
Inode 135260 was part of the orphaned inode list. IGNORED.
Inode 135263 was part of the orphaned inode list. IGNORED.
Inode 135268 was part of the orphaned inode list. IGNORED.
Deleted inode 135272 has zero dtime. Fix? no
Inode 135274 was part of the orphaned inode list. IGNORED.
Inode 135384 was part of the orphaned inode list. IGNORED.
Inode 135396 was part of the orphaned inode list. IGNORED.
Inode 135697 was part of the orphaned inode list. IGNORED.
Inode 135711 was part of the orphaned inode list. IGNORED.
Inode 135713 was part of the orphaned inode list. IGNORED.
Inode 12059086 was part of the orphaned inode list. IGNORED.
Inode 12061077 was part of the orphaned inode list. IGNORED.
Inode 12062594 was part of the orphaned inode list. IGNORED.
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences: -(40927357--40927367) -(40927563--40927569) -(40940652--40940653) -(40940676--40940681) -(48296964--48296970) -(48296978--48296984) -(48304145--48304165) -(48304315--48304321) -(48326677--48326690) -(48326733--48326739) -(48326775--48326781)
Fix? no
Free blocks count wrong (13857004, counted=13856542).
Fix? no
Inode bitmap differences: -131275 -135221 -135244 -135260 -135263 -135268 -135272 -135274 -135384 -135396 -135697 -135711 -135713 -12059086 -12061077 -12062594
Fix? no
Free inodes count wrong (14654909, counted=14654758).
Fix? no
/dev/nvme0n1p2: ********** WARNING: Filesystem still has errors **********
/dev/nvme0n1p2: 434755/15089664 files (0.3% non-contiguous), 46490132/60347136 blocks
Теперь моя проблема состоит в том, что я не могу зафиксировать те ошибки, так как это - мой системный раздел, который я не могу размонтировать. Но когда я загружаюсь от внешнего диска или в режиме восстановления, fsck не сообщает ни о каких ошибках, даже с-f. После перезагрузки моей системы, однако, сохраняются ошибки. Я в настоящее время в недоумении, как я смог фиксировать файловую систему. Любая справка значительно ценилась бы.
1 ответ
Если Вы вызываете проверку файловой системы в ext4 файловой системе, которая в настоящее время монтируется в использовании r/w-mode fsck -nf <filesystem>, Вы будете всегда получать сообщения об ошибках как те, Вы отправили (поврежденный связанный список висячей строки, Удаленный inode... имеет нуль dtime). Факт это fsck -n <filesystem> отчеты это как чистое является немного вводящим в заблуждение здесь.
Причиной Вы не видите эти ошибки в режиме восстановления или при начальной загрузке от внешнего диска является просто факт, это в этом случае, рассматриваемая файловая система не смонтирована в r/w-mode или даже не смонтирована вообще.
Страница руководства для e2fsck также явно указывает:
Обратите внимание, что в целом не безопасно выполнить e2fsck в смонтированных файловых системах. Единственное исключение - то, если-n опция указана, и-c,-l, или-L опции не указаны. Однако, даже если безопасно сделать так, результаты, распечатанные e2fsck, не допустимы, если файловая система смонтирована. Если e2fsck спрашивает, необходимо ли проверить файловую систему, которая смонтирована, единственный корректный ответ является ''нет''. Только эксперты, которые действительно знают то, что они делают, должны рассмотреть ответ на этот вопрос любым другим способом.
Заключение: Если Вы намереваетесь использовать -f флаг для fsck, удостоверьтесь, что Вы понимаете 100%, что он делает. В частности, использование его в смонтированной файловой системе обычно не, что Вы хотите.
Относительно того, почему Вы получаете ext4 ошибки при пробуждении от, приостанавливают, совершенно другая проблема, которую Вы, кажется, уже решили. По ссылочным причинам я буду включать ссылки, которые Вы отправили сами в комментарии здесь, когда они были полезны в решении Вашей исходной проблемы: