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

Обнаружили ошибку в тексте? Сообщите мне об этом. Выделите текст с ошибкой и нажмите Ctrl+Enter.

Если вкратце, то текущая проблема в том, что fsck находит, исправляет ошибки, но после перезагрузки они появляются опять.
Сектора (или блоки — хз, в общем циферки) в логах коррекции всегда те же самые.

Симптомы:
При загрузке системы постоянно чекался (правда после прогона из самой системы доходит до 100% без уведомлений)
После загрузки некоторое время система работает, но при обращении к некоторым программам/файлам переключается в readonly режим со всеми вытекающими — падают проги, ошибки записи в логи и прочее…

Предыстория. (Хронологический порядок обратный — от новых к старым)
0) сделал проверку Викторией на бэды — жестяк полностью жив, SMART в порядке
1) 3 раза сделал проверку с исправлением ошибок с помощью fsck, как из самой системы, так и из live CD
2) Около получаса использовал раздел EXT4 на винде при помощи Paragon ExtFS (работало медленно, поэтому сразу снёс и вернулся к ext2fsd)
3) Выполнил initramfs т.к. выскакивала ошибка при загрузке, что старый uuid не найден
4) Поправил файл fstab т.к. uuid раздела изменился
5) Восстанавливал GRUB загрузчик с помощью программы boot-repair64
6) Изменял размер/Перемещал раздел с Ubuntu (собсно с чего всё и началось :()
7) До манипуляций с разделами около года использовал ext раздел при помощи ext2fsd на виндах — проблем не было никаких

Вопрос
Что теперь делать?

Вот некоторые снимки процесса:
Фото1
Фото2
Фото3

Запускаю fsck из под рута в multi-user mode, получаю сообщения об ошибках ФС.
** /dev/ad4a (NO WRITE)
** Last Mounted on /
** Root file system
** Phase 1 — Check Blocks and Sizes
** Phase 2 — Check Pathnames
** Phase 3 — Check Connectivity
** Phase 4 — Check Reference Counts
UNREF FILE I=588828 OWNER=root MODE=100600
SIZE=0 MTIME=Aug 21 16:39 2008
CLEAR? no

** Phase 5 — Check Cyl groups
1117 files, 25905 used, 5557702 free (246 frags, 694682 blocks, 0.0% fragmentation)
** /dev/ad4d (NO WRITE)
** Last Mounted on /usr
** Phase 1 — Check Blocks and Sizes
** Phase 2 — Check Pathnames
** Phase 3 — Check Connectivity
** Phase 4 — Check Reference Counts
** Phase 5 — Check Cyl groups
506052 files, 5582561 used, 14728837 free (16197 frags, 1839080 blocks, 0.1% fragmentation)
** /dev/ad4e (NO WRITE)
** Last Mounted on /var
** Phase 1 — Check Blocks and Sizes
** Phase 2 — Check Pathnames
UNALLOCATED I=11567225 OWNER=www MODE=100600
SIZE=0 MTIME=Aug 21 16:40 2008
FILE=/www/xxxxxxxx.ru/temp/sess_dd5b4868ac3e5c40042fe602d9785103

REMOVE? no

** Phase 3 — Check Connectivity
** Phase 4 — Check Reference Counts
UNREF FILE I=541741 OWNER=mysql MODE=100600
SIZE=0 MTIME=Aug 21 16:39 2008
CLEAR? no

UNREF FILE I=541742 OWNER=mysql MODE=100600
SIZE=0 MTIME=Aug 21 16:39 2008
CLEAR? no

UNREF FILE I=541743 OWNER=mysql MODE=100600
SIZE=0 MTIME=Aug 21 16:39 2008
CLEAR? no

UNREF FILE I=541744 OWNER=mysql MODE=100600
SIZE=0 MTIME=Aug 21 16:39 2008
CLEAR? no

UNREF FILE I=541745 OWNER=mysql MODE=100600
SIZE=0 MTIME=Aug 21 16:39 2008
CLEAR? no

UNREF FILE I=20537356 OWNER=root MODE=140666
SIZE=0 MTIME=Aug 21 16:38 2008
CLEAR? no

** Phase 5 — Check Cyl groups
SUMMARY INFORMATION BAD
SALVAGE? no

BLK(S) MISSING IN BIT MAPS
SALVAGE? no

341489 files, 3800081 used, 86526999 free (10471 frags, 10814566 blocks, 0.0% fragmentation)

при запуске fsck из single-user mode (смонтирован только ‘/’ и то в read-only) ошибки не находятся и не исправляются. вывод fsck говорит о том что все проверки завершены успешно.

Вопрос знатокам: как же пофиксить ошибки файловой системы?

OC: FreeBSD 7.0 (amd64)
FS: UFS

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?