У меня был монтируемый fs (почти уверен, что это был ext3), fsck.ext4 запускался с -y и закончился ошибкой сегментации. Теперь его нельзя монтировать (dmesg сообщает, что он поврежден) и идентифицируется как ext4 fs с помощью команды "blkid". Файловая система находится на массиве raid 0, состоящем из трех разделов.
Поскольку я не на 100% уверен, что это изначально ext3, я не хочу запускать fsck.ext3. Я также понятия не имею, сработает ли это, даже если бы это было так.
Я надеюсь, что fsck достаточно умен, чтобы проверить тип fs и, по крайней мере, выдать предупреждение.
Мы будем очень благодарны за любые предложения о том, как избавиться от этого.
$ ls -la /sbin/fsck.ext?
lrwxrwxrwx 1 root root 6 jun 24 2013 /sbin/fsck.ext2 -> e2fsck
lrwxrwxrwx 1 root root 6 jun 24 2013 /sbin/fsck.ext3 -> e2fsck
lrwxrwxrwx 1 root root 6 jun 24 2013 /sbin/fsck.ext4 -> e2fsck
Итак, fsck, который вы запустили, является правильным. Если ваша файловая система теперь настолько повреждена, что не может монтироваться, у вас есть два варианта:
Вероятно, это программный RAID, но если вы видите блочное устройство, моя рекомендация по восстановлению данных на ext2 / 3/4, XFS и других файловых системах Linux: UFS Explorer. Это коммерческое программное обеспечение, но относительно недорогое.
Видеть как blkid возвращает правильный тип файловой системы, запуск сканирования UFS Explorer на устройстве (и перенаправления на другой диск) может быть чистым подходом к просмотру того, что можно восстановить, а что нет.
Обновление: Итак, любопытные, последний fsck (версия 2.24) смог завершить. Все полученные данные были в (утеряны + найдены). В настоящее время я создаю резервную копию этого каталога перед извлечением чего-либо. Однако на первый взгляд кажется, что большая часть данных есть. Так что это просто обход инодов, а не деревьев каталогов.
Спасибо за вашу помощь.