Fsck не исправляет ошибки

Страницы: [1]   Вниз

0 Пользователей и 1 Гость просматривают эту тему.

Страницы: [1]   Вверх

Из-за различных неполадок или неожиданного отключения компьютера файловая система может быть повреждена. При обычном выключении все файловые системы монтируются только для чтения, а все не сохраненные данные записываются на диск.

Но если питание выключается неожиданно, часть данных теряется, и могут быть потерянны важные данные, что приведет к повреждению самой файловой системы. В этой статье мы рассмотрим как восстановить файловую систему fsck, для нескольких популярных файловых систем, а также поговорим о том, как происходит восстановление ext4.

Немного теории

Как вы знаете файловая система содержит всю информацию обо всех хранимых на компьютере файлах. Это сами данные файлов и метаданные, которые управляют расположением и атрибутами файлов в файловой системе. Как я уже говорил, данные не сразу записываются на жесткий диск, а некоторое время находятся в оперативной памяти и при неожиданном выключении, за определенного стечения обстоятельств файловая система может быть повреждена.

Современные файловые системы делятся на два типа — журналируемые и нежурналируемые. Журналиуемые файловые системы записывают в лог все действия, которые собираются выполнить, а после выполнения стирают эти записи. Это позволяет очень быстро понять была ли файловая система повреждена. Но не сильно помогает при восстановлении. Чтобы восстановить файловую систему linux необходимо проверить каждый блок файловой системы и найти поврежденные сектора.

Для этих целей используется утилита fsck. По сути, это оболочка для других утилит, ориентированных на работу только с той или иной файловой системой, например, для fat одна утилита, а для ext4 совсем другая.

В большинстве систем для корневого раздела проверка fsck запускается автоматически, но это не касается других разделов, а также не сработает если вы отключили проверку.

В этой статье мы рассмотрим ручную работу с fsck. Возможно, вам понадобиться LiveCD носитель, чтобы запустить из него утилиту, если корневой раздел поврежден. Если же нет, то система сможет загрузиться в режим восстановления и вы будете использовать утилиту оттуда. Также вы можете запустить fsck в уже загруженной системе. Только для работы нужны права суперпользователя, поэтому выполняйте ее через sudo.

А теперь давайте рассмотрим сам синтаксис утилиты:

$ fsck [опции] [опции_файловой_системы] [раздел_диска]

Основные опции указывают способ поведения утилиты, оболочки fsck. Раздел диска — это файл устройства раздела в каталоге /dev, например, /dev/sda1 или /dev/sda2. Опции файловой системы специфичны для каждой отдельной утилиты проверки.

А теперь давайте рассмотрим самые полезные опции fsck:

• -l — не выполнять другой экземпляр fsck для этого жесткого диска, пока текущий не завершит работу. Для SSD параметр игнорируется;
• -t — задать типы файловых систем, которые нужно проверить. Необязательно указывать устройство, можно проверить несколько разделов одной командой, просто указав нужный тип файловой системы. Это может быть сама файловая система, например, ext4 или ее опции в формате opts=ro. Утилита просматривает все файловые системы, подключенные в fstab. Если задать еще и раздел то к нему будет применена проверка именно указанного типа, без автоопределения;
• -A — проверить все файловые системы из /etc/fstab. Вот тут применяются параметры проверки файловых систем, указанные в /etc/fstab, в том числе и приоритетность. В первую очередь проверяется корень. Обычно используется при старте системы;
• -C — показать прогресс проверки файловой системы;
• -M — не проверять, если файловая система смонтирована;
• -N — ничего не выполнять, показать, что проверка завершена успешно;
• -R — не проверять корневую файловую систему;
• -T — не показывать информацию об утилите;
• -V — максимально подробный вывод.

Это были глобальные опции утилиты. А теперь рассмотрим опции для работы с файловой системой, их меньше, но они будут более интересны:

• -a — во время проверки исправить все обнаруженные ошибки, без каких-либо вопросов. Опция устаревшая и ее использовать не рекомендуется;
• -n — выполнить только проверку файловой системы, ничего не исправлять;
• -r — спрашивать перед исправлением каждой ошибки, используется по умолчанию для файловых систем ext;
• -y — отвечает на все вопросы об исправлении ошибок утвердительно, можно сказать, что это эквивалент a.
• -c — найти и занести в черный список все битые блоки на жестком диске. Доступно только для ext3 и ext4;
• -f — принудительная проверка файловой системы, даже если по журналу она чистая;
• -b — задать адрес суперблока, если основной был поврежден;
• -p — еще один современный аналог опции -a, выполняет проверку и исправление автоматически. По сути, для этой цели можно использовать одну из трех опций: p, a, y.

Теперь мы все разобрали и вы готовы выполнять восстановление файловой системы linux. Перейдем к делу.

Как восстановить файловую систему в fsck

Допустим, вы уже загрузились в LiveCD систему или режим восстановления. Ну, одним словом, готовы к восстановлению ext4 или любой другой поврежденной ФС. Утилита уже установлена по умолчанию во всех дистрибутивах, так что устанавливать ничего не нужно.

Восстановление файловой системы

Если ваша файловая система находится на разделе с адресом /dev/sda1 выполните:

sudo fsck -y /dev/sda1

Опцию y указывать необязательно, но если этого не сделать утилита просто завалит вас вопросами, на которые нужно отвечать да.

Восстановление поврежденного суперблока

Обычно эта команда справляется со всеми повреждениями на ура. Но если вы сделали что-то серьезное и повредили суперблок, то тут fsck может не помочь. Суперблок — это начало файловой системы. Без него ничего работать не будет.

Но не спешите прощаться с вашими данными, все еще можно восстановить. С помощью такой команды смотрим куда были записаны резервные суперблоки:

sudo mkfs -t ext4 -n /dev/sda1

На самом деле эта команда создает новую файловую систему. Вместо ext4 подставьте ту файловую систему, в которую был отформатирован раздел, размер блока тоже должен совпадать иначе ничего не сработает. С опцией -n никаких изменений на диск не вноситься, а только выводится информация, в том числе о суперблоках.

Теперь у нас есть шесть резервных адресов суперблоков и мы можем попытаться восстановить файловую систему с помощью каждого из них, например:

sudo fsck -b 98304 /dev/sda1

После этого, скорее всего, вам удастся восстановить вашу файловую систему. Но рассмотрим еще пару примеров.

Проверка чистой файловой системы

Проверим файловую систему, даже если она чистая:

sudo fsck -fy /dev/sda1

Битые сектора

Или еще мы можем найти битые сектора и больше в них ничего не писать:

sudo fsck -c /dev/sda1

Установка файловой системы

Вы можете указать какую файловую систему нужно проверять на разделе, например:

sudo fsck -t ext4 /dev/sdb1

Проверка всех файловых систем

С помощью флага -A вы можете проверить все файловые системы, подключенные к компьютеру:

sudo fsck -A -y

Но такая команда сработает только в режиме восстановления, если корневой раздел и другие разделы уже примонтированы она выдаст ошибку. Но вы можете исключить корневой раздел из проверки добавив R:

sudo fsck -AR -y

Или исключить все примонтированные файловые системы:

sudo fsck -M -y

Также вы можете проверить не все файловые системы, а только ext4, для этого используйте такую комбинацию опций:

sudo fsck -A -t ext4 -y

Или можно также фильтровать по опциям монтирования в /etc/fstab, например, проверим файловые системы, которые монтируются только для чтения:

sudo fsck -A -t opts=ro

Проверка примонтированных файловых систем

Раньше я говорил что нельзя. Но если другого выхода нет, то можно, правда не рекомендуется. Для этого нужно сначала перемонтировать файловую систему в режим только для чтения. Например:

sudo mount -o remount,ro /dev/sdb1

А теперь проверка файловой системы fsck в принудительном режиме:

sudo fsck -fy /dev/sdb1

Просмотр информации

Если вы не хотите ничего исправлять, а только посмотреть информацию, используйте опцию -n:

sudo fsck -n /dev/sdb1

Выводы

Вот и все, теперь вы знаете как выполняется восстановление файловой системы ext4 или любой другой, поддерживаемой в linux fsck. Если у вас остались вопросы, спрашивайте в комментариях!

На десерт сегодня видео на английском про различия файловых систем ext4 и xfs, как обычно, есть титры:

https://www.youtube.com/watch?v=pECp066gGcY

There is a directory on one of my EXT4 partitions that an error, but fsck can’t seem to fix it.

# fsck -ClV -vpf /dev/mapper/enc_vols-home
fsck from util-linux 2.37
[/usr/bin/fsck.ext4 (1) -- /home] fsck.ext4 -vpf -C0 /dev/mapper/enc_vols-home 
Locking disk by /run/fsck/dm-1.lock ... succeeded.
                                                                               
     7541657 inodes used (6.18%, out of 122085376)
       36156 non-contiguous files (0.5%)
        3791 non-contiguous directories (0.1%)
             # of inodes with ind/dind/tind blocks: 0/0/0
             Extent depth histogram: 7516765/3959
   197726286 blocks used (40.49%, out of 488340480)
           0 bad blocks
          17 large files

     6501236 regular files
     1011955 directories
           0 character device files
           0 block device files
           3 fifos
         153 links
       28409 symbolic links (20877 fast symbolic links)
          45 sockets
------------
     7541801 files
Unlocking /run/fsck/dm-1.lock.
#
# mount /dev/mapper/enc_vols-home /mnt/home 
# find /mnt/home/foo/bar > /dev/null
[ 1188.983435] archlinux kernel: EXT4-fs error (device dm-1): ext4_lookup:1707: inode #27922002: comm find: iget: bad extra_isize 32700 (inode size 256)
[ 1188.986732] archlinux kernel: EXT4-fs error (device dm-1): ext4_lookup:1707: inode #27922002: comm find: iget: bad extra_isize 32700 (inode size 256)
find: ‘/mnt/home/foo/bar/foo2/foo3/foo4/foo5/foo6’: Structure needs cleaning
[ 1189.062658] archlinux kernel: EXT4-fs error (device dm-1): ext4_lookup:1707: inode #27922007: comm find: iget: bad extra_isize 17291 (inode size 256)
[ 1189.065903] archlinux kernel: EXT4-fs error (device dm-1): ext4_lookup:1707: inode #27922007: comm find: iget: bad extra_isize 17291 (inode size 256)
find: ‘/mnt/home/foo/bar/foo2/foo3/foo4/foo7’: Structure needs cleaning

I’ve also tried umounting the drive and running fsck again, but it doesn’t help — it still complains about that folder.

The partition is ext4 on LVM2 on LUKS on a RAID1 (mirror):

sdb                 sdb       /dev/sdb                    8:16                 linux_raid_member  
└─md127             md127     /dev/md127                  9:127                crypto_LUKS        
  └─enc_vols        dm-0      /dev/mapper/enc_vols      253:0                  LVM2_member        
    └─enc_vols-home dm-1      /dev/mapper/enc_vols-home 253:1   1015.4G   1.8T ext4               
sdc                 sdc       /dev/sdc                    8:32                 linux_raid_member  
└─md127             md127     /dev/md127                  9:127                crypto_LUKS        
  └─enc_vols        dm-0      /dev/mapper/enc_vols      253:0                  LVM2_member        
    └─enc_vols-home dm-1      /dev/mapper/enc_vols-home 253:1   1015.4G   1.8T ext4               

Both drives in the array are less than 2 years old and show no errors in SMART, though I have still not run fsck -c.

Why isn’t fsck finding the error, and how can I clean up this directory?

There is a directory on one of my EXT4 partitions that an error, but fsck can’t seem to fix it.

# fsck -ClV -vpf /dev/mapper/enc_vols-home
fsck from util-linux 2.37
[/usr/bin/fsck.ext4 (1) -- /home] fsck.ext4 -vpf -C0 /dev/mapper/enc_vols-home 
Locking disk by /run/fsck/dm-1.lock ... succeeded.
                                                                               
     7541657 inodes used (6.18%, out of 122085376)
       36156 non-contiguous files (0.5%)
        3791 non-contiguous directories (0.1%)
             # of inodes with ind/dind/tind blocks: 0/0/0
             Extent depth histogram: 7516765/3959
   197726286 blocks used (40.49%, out of 488340480)
           0 bad blocks
          17 large files

     6501236 regular files
     1011955 directories
           0 character device files
           0 block device files
           3 fifos
         153 links
       28409 symbolic links (20877 fast symbolic links)
          45 sockets
------------
     7541801 files
Unlocking /run/fsck/dm-1.lock.
#
# mount /dev/mapper/enc_vols-home /mnt/home 
# find /mnt/home/foo/bar > /dev/null
[ 1188.983435] archlinux kernel: EXT4-fs error (device dm-1): ext4_lookup:1707: inode #27922002: comm find: iget: bad extra_isize 32700 (inode size 256)
[ 1188.986732] archlinux kernel: EXT4-fs error (device dm-1): ext4_lookup:1707: inode #27922002: comm find: iget: bad extra_isize 32700 (inode size 256)
find: ‘/mnt/home/foo/bar/foo2/foo3/foo4/foo5/foo6’: Structure needs cleaning
[ 1189.062658] archlinux kernel: EXT4-fs error (device dm-1): ext4_lookup:1707: inode #27922007: comm find: iget: bad extra_isize 17291 (inode size 256)
[ 1189.065903] archlinux kernel: EXT4-fs error (device dm-1): ext4_lookup:1707: inode #27922007: comm find: iget: bad extra_isize 17291 (inode size 256)
find: ‘/mnt/home/foo/bar/foo2/foo3/foo4/foo7’: Structure needs cleaning

I’ve also tried umounting the drive and running fsck again, but it doesn’t help — it still complains about that folder.

The partition is ext4 on LVM2 on LUKS on a RAID1 (mirror):

sdb                 sdb       /dev/sdb                    8:16                 linux_raid_member  
└─md127             md127     /dev/md127                  9:127                crypto_LUKS        
  └─enc_vols        dm-0      /dev/mapper/enc_vols      253:0                  LVM2_member        
    └─enc_vols-home dm-1      /dev/mapper/enc_vols-home 253:1   1015.4G   1.8T ext4               
sdc                 sdc       /dev/sdc                    8:32                 linux_raid_member  
└─md127             md127     /dev/md127                  9:127                crypto_LUKS        
  └─enc_vols        dm-0      /dev/mapper/enc_vols      253:0                  LVM2_member        
    └─enc_vols-home dm-1      /dev/mapper/enc_vols-home 253:1   1015.4G   1.8T ext4               

Both drives in the array are less than 2 years old and show no errors in SMART, though I have still not run fsck -c.

Why isn’t fsck finding the error, and how can I clean up this directory?

Команда FSCK (Проверка согласованности файловой системы) — это команда предназначена для проверки и исправления ошибок файловой системы Linux. Что гарантирует целостность и согласованность файловой системы.

fsck — это интерфейсная утилита, которая вызывает программу для проверки конкретной файловой системы. Команда Fsck обычно запускается после сбоя загрузки системы, повреждения файловой системы или сбоя в работе подключенного диска.

Например в системе Windows есть подобная утилита, называется chkdsk.

В этой статье мы расскажем о команде fsck и о том, как восстановить систему в дистрибутиве Linux.

Требования:

• Установленная система Linux или Unix-подобная
• Пользователь с правами Sudo (суперпользователь)

Что делает команда fsck

• Система автоматически обнаруживает несогласованность системы, как правило после сбоя системы или потери питания или после неправильного отключения.
• Используйте fsck если система не загружается
• Исправление ошибок ввода-вывода
• Запланированный запуск fsck для проверки файловой системы при загрузке ОС.

Команда fsck в Linux

Команда fsck имеет вот такой синтаксис.

$ sudo fsck [Опция] [Файловая система]

[Опция] в синтаксисе — это параметры, доступные с помощью утилиты fsck (различные опции fsck приведены в конце этой статьи).

[Файловая система] может быть устройством, разделом, точкой монтирования и так далее. Если учетные данные не добавлены в [Файловую систему], fsck проверяет устройства, перечисленные в файле fstab.

fsck по умолчанию включен во все дистрибутивы Linux. Команда fsck проверяет все файлы и целостность файловой системы. Эту команду можно выполнить вручную или автоматически.

ВНИМАНИЕ: Прежде чем пытаться проверить или восстановить файловую систему, всегда помните о необходимости размонтирования раздела. Если этого не сделать, файловая система может быть повреждена.

Проверка и исправление ошибок файловой системы в Linux

Fsck обычно используется для исправления ошибок в поврежденных файловых системах ext3 или ext4. Чтобы использовать утилиту fsck, вы должны сначала убедиться, что раздел был размонтирован. Вы получите сообщение об ошибке и ваш процесс будет прерван, если вы попытаетесь запустить команду fsck в разделе не размонтировав его. После завершения процесса вы можете снова смонтировать файловую систему.

Если вы не уверены в имени устройства которое хотите проверить, используйте команду df, lsblk или fdisk (fdisk-l), чтобы найти его.

$ sudo df -h

Используйте команду размонтировать, чтобы избежать повреждения файловой системы.

Синтаксис команды размонтирования:

$ sudo umount [filesystem]

Вы можете использовать опцию -p вместе с утилитой fsck для автоматического устранения любых проблем, которые будут безопасно устранены без вмешательства пользователя.

Синтаксис команды проверки файловой системы и файлов:

$ sudo fsck -p [Filesystem]

Пример использования команд :

$ sudo umount /dev/sdc
$ sudo fsck -p /dev/sdc

Ответ в терминала:

$ sudo fsck -p /dev/sdc
fsck from util-linux 2.34
exfatfsck 1.3.0
Checking file system on /dev/sdc.
File system version              1.0
Sector size                      512 bytes
Cluster size                     128 KB
Volume size                      55 GB
Used space                       4 MB
Available space                  55 GB
Totally 1 directories and 3 files.
File system checking finished. No errors found.

После проверки и ремонта обязательно смонтируйте диск.

Исправление ошибки корневой файловой системы Linux командой fsck

Поскольку корневая система не может быть отключена, Fsck не может проверять наличие ошибок. Но у вас есть возможность запустить fsck в режиме восстановления.

Перезагрузив компьютер в режиме аварийного восстановления, вы можете запустить fsck. Чтобы запустить fsck для исправления ошибок файлов корневой системы, выполнив следующие действия.

Войдите в меню загрузки и выберите «Дополнительные параметры»  (Advanced Options).

Теперь выберите “Режим восстановления” (Recovery mode), а затем в меню выберите» fsck” .

Далее появится окно сообщения с вопросом, хотите ли вы переустановить свою / файловую систему. Выберите опцию «Да«.

Теперь нажмите «ДА» и вернитесь к нормальной загрузке.

Параметры fsck

Существует список опций (параметров), которые доступны с помощью утилиты fsck. Все они используются для конкретных целей. Вот некоторые полезные опций fsck:

1. Perform fsck dry run — это выполнение тестового запуска.

fsck -N /dev/sdc

2. Опция -y на все вопросы автоматически ответит ДА, это позволит избежать всех подсказок

fsck -y /dev/sdc

3. Параметр -n  выведите ошибку fsck без ремонта

fsck -n /dev/sdc

4. Запуск fsck во всех файловых системах

fsck -AR

-R  пропустит корневую файловую систему, так как ее нельзя размонтировать на работающей машине

5. Запуск fsck для определенной файловой системы

Команда fsck является оболочкой и внутренне использует соответствующую команду проверки файловой системы (fsck.*). Вы можете найти следующие различные команды проверки fsck, такие как fsck.ext2, fsck.ext3, fsck.ext4 и т.д.).

# cd /sbin
# ls fsck*
fsck fsck.cramfs fsck.ext2 fsck.ext3 fsck.ext4 fsck.minix fsck.xfs

В следующей таблице показаны все параметры (опции) команды fsck.

Параметры fsck

fstab — это файл, который указывает операционной системе, как и где монтировать разделы. Вы так же можете найти список записей в файле fstab /etc/fstab.

Параметр  <pass> определяет порядок, в котором выполняются проверки файловых системы во время перезагрузки. Если значение равно 0, то оно не проверяется. Если значение равно 1, файловые системы проверяются по одной за раз. А если значение равно 2, поиск во всех файловых системах выполняется одновременно. Значение корневой файловой системы равно 1, а все остальные файловые системы, которые вы хотите проверить, должны иметь значение 2.

Образец файла /etc/fstab:

Заключение

В этой статье мы показали, как использовать команду fsck для проверки и восстановления файловых систем в Linux. Вы так же можете ознакомиться со справочным материалом fsck для более подробного изучения.

Код: Выделить всё

fsck -y /dev/aacd0s1f
** /dev/aacd0s1f (NO WRITE)
** Last Mounted on /usr
** Phase 1 - Check Blocks and Sizes
CANNOT READ BLK: 196032672
UNEXPECTED SOFT UPDATE INCONSISTENCY

CONTINUE? yes

THE FOLLOWING DISK SECTORS COULD NOT BE READ: 196032672, 196032673, 196032674, 196032675, 196032676, 196032677, 196032678, 196032679, 196032680, 196032681, 196032682, 196032683, 196032684, 196032685, 196032686, 196032687, 196032688, 196032689, 196032690, 196032691, 196032692, 196032693, 196032694, 196032695, 196032696, 196032697, 196032698, 196032699, 196032700, 196032701, 196032702, 196032703, 196032704,
** Phase 2 - Check Pathnames

NAME=/share/man/man3/curs_in_wch.3.gz

UNEXPECTED SOFT UPDATE INCONSISTENCY

REMOVE? no

UNALLOCATED  I=12276744  OWNER=root MODE=0
SIZE=0 MTIME=Jan  1 03:00 1970

CANNOT READ BLK: 196032672
UNEXPECTED SOFT UPDATE INCONSISTENCY

CONTINUE? yes

THE FOLLOWING DISK SECTORS COULD NOT BE READ: 196032672, 196032673, 196032674, 196032675, 196032676, 196032677, 196032678, 196032679, 196032680, 196032681, 196032682, 196032683, 196032684, 196032685, 196032686, 196032687, 196032688, 196032689, 196032690, 196032691, 196032692, 196032693, 196032694, 196032695, 196032696, 196032697, 196032698, 196032699, 196032700, 196032701, 196032702, 196032703,
NAME=/share/man/man3/innwstr.3.gz

UNEXPECTED SOFT UPDATE INCONSISTENCY

REMOVE? no

UNALLOCATED  I=12276744  OWNER=root MODE=0
SIZE=0 MTIME=Jan  1 03:00 1970

CANNOT READ BLK: 196032672
UNEXPECTED SOFT UPDATE INCONSISTENCY

CONTINUE? yes

THE FOLLOWING DISK SECTORS COULD NOT BE READ: 196032672, 196032673, 196032674, 196032675, 196032676, 196032677, 196032678, 196032679, 196032680, 196032681, 196032682, 196032683, 196032684, 196032685, 196032686, 196032687, 196032688, 196032689, 196032690, 196032691, 196032692, 196032693, 196032694, 196032695, 196032696, 196032697, 196032698, 196032699, 196032700, 196032701, 196032702, 196032703,
NAME=/share/man/man3/innwstr.3.gz

UNEXPECTED SOFT UPDATE INCONSISTENCY

REMOVE? no

UNALLOCATED  I=12276744  OWNER=root MODE=0
SIZE=0 MTIME=Jan  1 03:00 1970

CANNOT READ BLK: 196032672
UNEXPECTED SOFT UPDATE INCONSISTENCY

CONTINUE? yes

THE FOLLOWING DISK SECTORS COULD NOT BE READ: 196032672, 196032673, 196032674, 196032675, 196032676, 196032677, 196032678, 196032679, 196032680, 196032681, 196032682, 196032683, 196032684, 196032685, 196032686, 196032687, 196032688, 196032689, 196032690, 196032691, 196032692, 196032693, 196032694, 196032695, 196032696, 196032697, 196032698, 196032699, 196032700, 196032701, 196032702, 196032703,
NAME=/share/man/man3/innwstr.3.gz

UNEXPECTED SOFT UPDATE INCONSISTENCY

REMOVE? no

UNALLOCATED  I=12276744  OWNER=root MODE=0
SIZE=0 MTIME=Jan  1 03:00 1970

CANNOT READ BLK: 196032672
UNEXPECTED SOFT UPDATE INCONSISTENCY

CONTINUE? yes

THE FOLLOWING DISK SECTORS COULD NOT BE READ: 196032672, 196032673, 196032674, 196032675, 196032676, 196032677, 196032678, 196032679, 196032680, 196032681, 196032682, 196032683, 196032684, 196032685, 196032686, 196032687, 196032688, 196032689, 196032690, 196032691, 196032692, 196032693, 196032694, 196032695, 196032696, 196032697, 196032698, 196032699, 196032700, 196032701, 196032702, 196032703,
NAME=/share/man/man3/innwstr.3.gz

UNEXPECTED SOFT UPDATE INCONSISTENCY

REMOVE? no

UNALLOCATED  I=12276744  OWNER=root MODE=0
SIZE=0 MTIME=Jan  1 03:00 1970

CANNOT READ BLK: 196032672
UNEXPECTED SOFT UPDATE INCONSISTENCY

CONTINUE? yes

THE FOLLOWING DISK SECTORS COULD NOT BE READ: 196032672, 196032673, 196032674, 196032675, 196032676, 196032677, 196032678, 196032679, 196032680, 196032681, 196032682, 196032683, 196032684, 196032685, 196032686, 196032687, 196032688, 196032689, 196032690, 196032691, 196032692, 196032693, 196032694, 196032695, 196032696, 196032697, 196032698, 196032699, 196032700, 196032701, 196032702, 196032703,
NAME=/share/man/man3/innwstr.3.gz

UNEXPECTED SOFT UPDATE INCONSISTENCY

REMOVE? no

UNALLOCATED  I=12276744  OWNER=root MODE=0
SIZE=0 MTIME=Jan  1 03:00 1970

CANNOT READ BLK: 196032672
UNEXPECTED SOFT UPDATE INCONSISTENCY

CONTINUE? yes

THE FOLLOWING DISK SECTORS COULD NOT BE READ: 196032672, 196032673, 196032674, 196032675, 196032676, 196032677, 196032678, 196032679, 196032680, 196032681, 196032682, 196032683, 196032684, 196032685, 196032686, 196032687, 196032688, 196032689, 196032690, 196032691, 196032692, 196032693, 196032694, 196032695, 196032696, 196032697, 196032698, 196032699, 196032700, 196032701, 196032702, 196032703,
NAME=/share/man/man3/innwstr.3.gz

UNEXPECTED SOFT UPDATE INCONSISTENCY

REMOVE? no

UNALLOCATED  I=12276744  OWNER=root MODE=0
SIZE=0 MTIME=Jan  1 03:00 1970

CANNOT READ BLK: 196032672
UNEXPECTED SOFT UPDATE INCONSISTENCY

CONTINUE? yes

THE FOLLOWING DISK SECTORS COULD NOT BE READ: 196032672, 196032673, 196032674, 196032675, 196032676, 196032677, 196032678, 196032679, 196032680, 196032681, 196032682, 196032683, 196032684, 196032685, 196032686, 196032687, 196032688, 196032689, 196032690, 196032691, 196032692, 196032693, 196032694, 196032695, 196032696, 196032697, 196032698, 196032699, 196032700, 196032701, 196032702, 196032703,
NAME=/share/man/man3/innwstr.3.gz

UNEXPECTED SOFT UPDATE INCONSISTENCY

REMOVE? no

UNALLOCATED  I=12276744  OWNER=root MODE=0
SIZE=0 MTIME=Jan  1 03:00 1970

CANNOT READ BLK: 196032672
UNEXPECTED SOFT UPDATE INCONSISTENCY

CONTINUE? yes

THE FOLLOWING DISK SECTORS COULD NOT BE READ: 196032672, 196032673, 196032674, 196032675, 196032676, 196032677, 196032678, 196032679, 196032680, 196032681, 196032682, 196032683, 196032684, 196032685, 196032686, 196032687, 196032688, 196032689, 196032690, 196032691, 196032692, 196032693, 196032694, 196032695, 196032696, 196032697, 196032698, 196032699, 196032700, 196032701, 196032702, 196032703,
NAME=/share/man/man3/innwstr.3.gz

UNEXPECTED SOFT UPDATE INCONSISTENCY

REMOVE? no

** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
UNREF FILE I=3274030  OWNER=root MODE=140666
SIZE=0 MTIME=Sep 15 11:57 2011
CLEAR? no

UNREF FILE I=3274098  OWNER=root MODE=140666
SIZE=0 MTIME=Jun 20 15:16 2012
CLEAR? no

UNREF FILE I=3274103  OWNER=mysql MODE=100600
SIZE=0 MTIME=Sep 15 11:57 2011
CLEAR? no

UNREF FILE I=3274118  OWNER=mysql MODE=100600
SIZE=0 MTIME=Sep 15 11:57 2011
CLEAR? no

UNREF FILE I=3274130  OWNER=mysql MODE=100600
SIZE=0 MTIME=Jun 20 15:16 2012
CLEAR? no

UNREF FILE I=3274131  OWNER=mysql MODE=100600
SIZE=0 MTIME=Jun 20 15:16 2012
CLEAR? no

UNREF FILE I=3274147  OWNER=mysql MODE=100600
SIZE=0 MTIME=Sep 15 11:57 2011
CLEAR? no

UNREF FILE I=3274153  OWNER=mysql MODE=100600
SIZE=0 MTIME=Jun 20 15:16 2012
CLEAR? no

UNREF FILE I=3274158  OWNER=mysql MODE=100600
SIZE=0 MTIME=Jun 20 15:16 2012
CLEAR? no

UNREF FILE I=3274166  OWNER=mysql MODE=100600
SIZE=0 MTIME=Jun 20 15:16 2012
CLEAR? no

UNREF FILE I=3274174  OWNER=mysql MODE=100600
SIZE=0 MTIME=Sep 15 11:57 2011
CLEAR? no

UNREF FILE I=3274212  OWNER=mysql MODE=100600
SIZE=0 MTIME=Sep 15 11:57 2011
CLEAR? no

UNREF FILE I=4710459  OWNER=mysql MODE=100600
SIZE=0 MTIME=Jun 20 15:12 2012
CLEAR? no

UNREF FILE I=4710462  OWNER=mysql MODE=100600
SIZE=0 MTIME=Jun 20 15:12 2012
CLEAR? no

UNREF FILE I=4710463  OWNER=mysql MODE=100600
SIZE=0 MTIME=Jun 20 15:12 2012
CLEAR? no

UNREF FILE I=4710464  OWNER=mysql MODE=100600
SIZE=0 MTIME=Jun 20 15:12 2012
CLEAR? no

UNREF FILE I=4710465  OWNER=mysql MODE=100600
SIZE=0 MTIME=Jun 20 15:12 2012
CLEAR? no

UNREF FILE I=4710522  OWNER=www MODE=140700
SIZE=0 MTIME=May 11 00:57 2012
CLEAR? no

UNREF FILE I=4710991  OWNER=mysql MODE=100600
SIZE=0 MTIME=Aug  1 11:23 2011
CLEAR? no

UNREF FILE I=4710992  OWNER=mysql MODE=100600
SIZE=581 MTIME=Mar 26 17:29 2012
CLEAR? no

UNREF FILE I=4710993  OWNER=mysql MODE=100600
SIZE=146 MTIME=Sep  5 16:22 2011
CLEAR? no

UNREF FILE I=4710994  OWNER=mysql MODE=100600
SIZE=0 MTIME=Aug  1 11:23 2011
CLEAR? no

UNREF FILE I=4710996  OWNER=mysql MODE=100600
SIZE=1342 MTIME=Sep  5 16:22 2011
CLEAR? no

UNREF FILE I=4711036  OWNER=www MODE=140700
SIZE=0 MTIME=May 11 00:43 2012
CLEAR? no

** Phase 5 - Check Cyl groups
FREE BLK COUNT(S) WRONG IN SUPERBLK
SALVAGE? no

SUMMARY INFORMATION BAD
SALVAGE? no

BLK(S) MISSING IN BIT MAPS
SALVAGE? no

ALLOCATED FRAGS 19192096-19192101 MARKED FREE
1367709 files, 28252075 used, 22352987 free (104947 frags, 2781005 blocks, 0.2% fragmentation)

Код: Выделить всё

Jun 21 19:28:41 host kernel: aacd0: hard error cmd=read fsbn 334444783
Jun 21 19:28:41 host kernel: aacd0: hard error cmd=read fsbn 334444784
Jun 21 19:28:41 host kernel: aacd0: hard error cmd=read fsbn 334444785
Jun 21 19:28:41 host kernel: aacd0: hard error cmd=read fsbn 334444786
Jun 21 19:28:41 host kernel: aacd0: hard error cmd=read fsbn 334444787
Jun 21 19:28:41 host kernel: aacd0: hard error cmd=read fsbn 334444788
Jun 21 19:28:41 host kernel: aacd0: hard error cmd=read fsbn 334444789
Jun 21 19:28:41 host kernel: aacd0: hard error cmd=read fsbn 334444790
Jun 21 19:28:41 host kernel: aacd0: hard error cmd=read fsbn 334444791
Jun 21 19:28:41 host kernel: aacd0: hard error cmd=read fsbn 334444792
Jun 21 19:28:41 host kernel: aacd0: hard error cmd=read fsbn 334444793
Jun 21 19:28:41 host kernel: aacd0: hard error cmd=read fsbn 334444794
Jun 21 19:28:41 host kernel: aacd0: hard error cmd=read fsbn 334444795
Jun 21 19:28:41 host kernel: aacd0: hard error cmd=read fsbn 334444796
Jun 21 19:28:41 host kernel: aacd0: hard error cmd=read fsbn 334444797
Jun 21 19:28:41 host kernel: aacd0: hard error cmd=read fsbn 334444798
Jun 21 19:28:41 host kernel: aacd0: hard error cmd=read 334444767-334444798
Jun 21 19:28:41 host kernel: aacd0: hard error cmd=read fsbn 334444767
Jun 21 19:28:41 host kernel: aacd0: hard error cmd=read fsbn 334444768
Jun 21 19:28:41 host kernel: aacd0: hard error cmd=read fsbn 334444769
Jun 21 19:28:41 host kernel: aacd0: hard error cmd=read fsbn 334444770
Jun 21 19:28:41 host kernel: aacd0: hard error cmd=read fsbn 334444771
Jun 21 19:28:41 host kernel: aacd0: hard error cmd=read fsbn 334444772
Jun 21 19:28:41 host kernel: aacd0: hard error cmd=read fsbn 334444773
Jun 21 19:28:41 host kernel: aacd0: hard error cmd=read fsbn 334444774
Jun 21 19:28:41 host kernel: aacd0: hard error cmd=read fsbn 334444775
Jun 21 19:28:41 host kernel: aacd0: hard error cmd=read fsbn 334444776
Jun 21 19:28:42 host kernel: aacd0: hard error cmd=read fsbn 334444777
Jun 21 19:28:42 host kernel: aacd0: hard error cmd=read fsbn 334444778
Jun 21 19:28:42 host kernel: aacd0: hard error cmd=read fsbn 334444779
Jun 21 19:28:42 host kernel: aacd0: hard error cmd=read fsbn 334444780
Jun 21 19:28:42 host kernel: aacd0: hard error cmd=read fsbn 334444781
Jun 21 19:28:42 host kernel: aacd0: hard error cmd=read fsbn 334444782
Jun 21 19:28:42 host kernel: aacd0: hard error cmd=read fsbn 334444783
Jun 21 19:28:42 host kernel: aacd0: hard error cmd=read fsbn 334444784
Jun 21 19:28:42 host kernel: aacd0: hard error cmd=read fsbn 334444785
Jun 21 19:28:42 host kernel: aacd0: hard error cmd=read fsbn 334444786
Jun 21 19:28:42 host kernel: aacd0: hard error cmd=read fsbn 334444787
Jun 21 19:28:42 host kernel: aacd0: hard error cmd=read fsbn 334444788
Jun 21 19:28:42 host kernel: aacd0: hard error cmd=read fsbn 334444789
Jun 21 19:28:42 host kernel: aacd0: hard error cmd=read fsbn 334444790
Jun 21 19:28:42 host kernel: aacd0: hard error cmd=read fsbn 334444791
Jun 21 19:28:42 host kernel: aacd0: hard error cmd=read fsbn 334444792
Jun 21 19:28:42 host kernel: aacd0: hard error cmd=read fsbn 334444793
Jun 21 19:28:42 host kernel: aacd0: hard error cmd=read fsbn 334444794
Jun 21 19:28:42 host kernel: aacd0: hard error cmd=read fsbn 334444795
Jun 21 19:28:42 host kernel: aacd0: hard error cmd=read fsbn 334444796
Jun 21 19:28:42 host kernel: aacd0: hard error cmd=read fsbn 334444797
Jun 21 19:28:42 host kernel: aacd0: hard error cmd=read fsbn 334444798
Jun 21 19:28:42 host kernel: aacd0: hard error cmd=read 334444767-334444798
Jun 21 19:28:42 host kernel: aacd0: hard error cmd=read fsbn 334444767
Jun 21 19:28:42 host kernel: aacd0: hard error cmd=read fsbn 334444768
Jun 21 19:28:42 host kernel: aacd0: hard error cmd=read fsbn 334444769
Jun 21 19:28:42 host kernel: aacd0: hard error cmd=read fsbn 334444770
Jun 21 19:28:43 host kernel: aacd0: hard error cmd=read fsbn 334444771
Jun 21 19:28:43 host kernel: aacd0: hard error cmd=read fsbn 334444772
Jun 21 19:28:43 host kernel: aacd0: hard error cmd=read fsbn 334444773
Jun 21 19:28:43 host kernel: aacd0: hard error cmd=read fsbn 334444774
Jun 21 19:28:43 host kernel: aacd0: hard error cmd=read fsbn 334444775
Jun 21 19:28:43 host kernel: aacd0: hard error cmd=read fsbn 334444776
Jun 21 19:28:43 host kernel: aacd0: hard error cmd=read fsbn 334444777
Jun 21 19:28:43 host kernel: aacd0: hard error cmd=read fsbn 334444778
Jun 21 19:28:43 host kernel: aacd0: hard error cmd=read fsbn 334444779
Jun 21 19:28:43 host kernel: aacd0: hard error cmd=read fsbn 334444780
Jun 21 19:28:43 host kernel: aacd0: hard error cmd=read fsbn 334444781
Jun 21 19:28:43 host kernel: aacd0: hard error cmd=read fsbn 334444782
Jun 21 19:28:43 host kernel: aacd0: hard error cmd=read fsbn 334444783
Jun 21 19:28:43 host kernel: aacd0: hard error cmd=read fsbn 334444784
Jun 21 19:28:43 host kernel: aacd0: hard error cmd=read fsbn 334444785
Jun 21 19:28:43 host kernel: aacd0: hard error cmd=read fsbn 334444786
Jun 21 19:28:43 host kernel: aacd0: hard error cmd=read fsbn 334444787
Jun 21 19:28:43 host kernel: aacd0: hard error cmd=read fsbn 334444788
Jun 21 19:28:43 host kernel: aacd0: hard error cmd=read fsbn 334444789
Jun 21 19:28:43 host kernel: aacd0: hard error cmd=read fsbn 334444790
Jun 21 19:28:43 host kernel: aacd0: hard error cmd=read fsbn 334444791
Jun 21 19:28:43 host kernel: aacd0: hard error cmd=read fsbn 334444792
Jun 21 19:28:43 host kernel: aacd0: hard error cmd=read fsbn 334444793
Jun 21 19:28:43 host kernel: aacd0: hard error cmd=read fsbn 334444794
Jun 21 19:28:43 host kernel: aacd0: hard error cmd=read fsbn 334444795
Jun 21 19:28:43 host kernel: aacd0: hard error cmd=read fsbn 334444796
Jun 21 19:28:44 host kernel: aacd0: hard error cmd=read fsbn 334444797
Jun 21 19:28:44 host kernel: aacd0: hard error cmd=read fsbn 334444798
Jun 21 19:28:44 host kernel: aacd0: hard error cmd=read 334444767-334444798
Jun 21 19:28:44 host kernel: aacd0: hard error cmd=read fsbn 334444767
Jun 21 19:28:44 host kernel: aacd0: hard error cmd=read fsbn 334444768
Jun 21 19:28:44 host kernel: aacd0: hard error cmd=read fsbn 334444769
Jun 21 19:28:44 host kernel: aacd0: hard error cmd=read fsbn 334444770

Состояние перевода: На этой странице представлен перевод статьи fsck. Дата последней синхронизации: 10 июля 2021. Вы можете помочь синхронизировать перевод, если в английской версии произошли изменения.

fsck (file system check) — утилита для проверки и восстановления файловых систем Linux. Проверка файловых систем разных физических дисков выполняется параллельно, что позволяет значительно её ускорить (см. fsck(8)).

Процесс загрузки Arch включает в себя процедуру fsck, поэтому проверка файловых систем на всех носителях выполняется автоматически при каждой загрузке. По этой причине обычно нет необходимости выполнять её через командную строку.

Проверка при загрузке

Механизм

Существует два возможных варианта:

1. mkinitcpio предоставляет хук fsck для проверки корневой файловой системы перед монтированием. Корневой раздел должен быть смонтирован на запись и чтение (параметр ядра rw) [1].
2. systemd проверяет все файловые системы, которым задано значение fsck больше 0 (либо параметром fstab, либо в пользовательском файле юнита). Корневая файловая система изначально должна быть смонтирована только на чтение (параметр ядра ro), и лишь позже перемонтирована на чтение-запись в fstab. Имейте в виду, что опция монтирования defaults подразумевает rw.

Рекомендуется по умолчанию использовать первый вариант. Если вы устанавливали систему в соответствии с руководством, то использоваться будет именно он. Если вы хотите вместо этого использовать вариант 2, то удалите хук fsck из mkinitcpio.conf и задайте параметр ядра ro. Кроме того, параметром ядра fsck.mode=skip можно полностью отключить fsck для обоих вариантов.

Принудительная проверка

Если вы используете base-хук mkinitcpio, то можно принудительно выполнять fsck во время загрузки, задав параметр ядра fsck.mode=force. Проверена будет каждая файловая система на машине.

В качестве альтернативы можно воспользоваться службой systemd systemd-fsck@.service(8), которая проверит все настроенные файловые системы, которые не были проверены в initramfs. Тем не менее, проверка корневой файловой системы этим способом может стать причиной задержки в время загрузки, поскольку файловая система будет перемонтироваться.

Примечание: Если вы используете другие дистрибутивы GNU/Linux, то учтите, что старые методы проверки вроде файлов forcefsck для каждой файловой системы или команды shutdown с флагом -F будут работать только с SysVinit и ранними версиями Upstart; работать с systemd они не будут. Решение, предложенное выше, является единственным рабочим для Arch Linux.

Советы и рекомандации

Восстановление повреждённых блоков

Следующая команда позволяет восстановить повреждённые участки файловых систем ext2/ext3/ext4 и FAT:

Важно: Разрешение на восстановление запрошено не будет. Подразумевается, что вы уже ответили «Да», запустив команду на выполнение.

# fsck -a

Интерактивное восстановление повреждённых блоков

Полезно в том случае, если файлы на загрузочном разделе были изменены, а журнал не обновился соответствующим образом. В этом случае размонтируйте загрузочный раздел и выполните:

# fsck -r диск

Изменение частоты проверки

Примечание: Команды tune2fs и dumpe2fs работают только с файловыми системами ext2/ext3/ext4.

По умолчанию fsck проверяет файловую систему каждые 30 загрузок (вычисляется отдельно для каждого раздела). Чтобы изменить частотку проверок, выполните:

# tune2fs -c 20 /dev/sda1

Здесь 20 — число загрузок между проверками. Если задать значение 1, то проверка будет выполняться при каждой загрузке, а значение 0 отключит сканирование.

Текущую частоту проверок и опции монтирования конкретного раздела можно узнать командой:

# dumpe2fs -h /dev/sda1 | grep -i 'mount count'

Параметры fstab

fstab — файл системных настроек, который используется для передачи ядру Linux информации о том, какие разделы (файловые системы) монтировать и в какие точки дерева файловой системы.

Записи в /etc/fstab выглядят примерно следующим образом.

/dev/sda1   /         ext4      defaults       0  1
/dev/sda2   /other    ext4      defaults       0  2
/dev/sda3   /win      ntfs-3g   defaults       0  0

Шестое поле каждой строки (выделено) — опция fsck:

• 0 — не проверять.
• 1 — файловая система (раздел), которая должна быть проверена первой; для корневого раздела (/) должно использоваться именно это значение.
• 2 — прочие файловые системы, которые должны быть проверены.

Решение проблем

Не запускается fsck для отдельного раздела /usr

1. Убедитесь, что используются соответствующие хуки в /etc/mkinitcpio.conf, а также что вы не забыли пересоздать initramfs после последнего редактирования этого файла.
2. Проверьте fstab! Только корневому разделу должен быть задан параметр 1 в последнем поле, все остальные разделы должны иметь либо 2, либо 0. Также проверьте файл на наличие иных опечаток.

ext2fs: no external journal

Иногда (например, из-за внезапного отключения питания) файловые системы ext(3/4) могут повредиться так сильно, что восстановить их обычным способом не удастся. Как правило, при этом fsck выводит сообщение о том, что не удалось найти журнал (no external journal). В этом случае выполните команды ниже.

Отмонтируйте раздел от соответствующего каталога:

# umount каталог

Запишите на раздел новый журнал:

# tune2fs -j /dev/раздел

Запустите fsck, чтобы восстановить раздел:

# fsck -p /dev/раздел