Вопрос Есть ли в Linux неуправляемые файлы?


Я никогда не видел этого раньше (20 лет * nix). Я пытался сохранить мой жесткий диск (подробности по запросу) и был довольно успешным, за исключением некоторых файлов, которые выглядят следующим образом:

$ ls -al
$ ?????????? ?    ?       ?      ? blah.txt

На этот файл не влияют rm, rm -f, shred, mv, chown, chmod или любая другая команда, о которой я могу думать.

пример

# whoami
root

# rm -f blah.txt
rm: cannot remove `blah.txt': permission denied

# ls -la blah.txt
?????????? ?    ?       ?      ? blah.txt

В принципе то же самое для любых команд в этом файле.

Есть идеи?


4
2017-12-13 07:46


происхождения


20 лет Unix, и вы еще не видели поврежденную файловую систему и / или сломанные HD? Повезло тебе. - Janne Pikkarainen
Ах, вот что я подумал. Да, наверное, мне повезло. HD не сломан, кстати. Работает отлично. - bev
Это обычно означает, что имя файла указано в каталоге, но не может получить доступ к его inode. Он может иметь плохой номер inode в каталоге, иначе inode на диске может быть поврежден. - mark4o


ответы:


Можете ли вы показать нам вывод «lsattr blah.txt»? Это сообщит нам, какие специальные флаги установлен в этом файле.

Можете ли вы также проверить dmesg (журнал сообщений об отладке ядра) для чего-либо нового (дважды запустите dmesg, один раз перед попытками удалить файл, после этого, и посмотрите, появилось ли что-нибудь новое в нижней части журнала).

Пример сообщения об ошибке файловой системы может выглядеть так:

[86777.332361] EXT4-fs (dm-0): error count: 436
[86777.332365] EXT4-fs (dm-0): initial error at 1290174395: ext4_mb_generate_buddy:726
[86777.332367] EXT4-fs (dm-0): last error at 1292151653: ext4_mb_generate_buddy:726
[86777.332419] EXT4-fs (dm-8): error count: 1406
[86777.332423] EXT4-fs (dm-8): initial error at 1290623933: ext4_mb_generate_buddy:726
[86777.332425] EXT4-fs (dm-8): last error at 1292168399: ext4_mb_generate_buddy:726

и это означает, что ~ 86777 секунд с момента загрузки (эта часть может не отображаться в вашей системе, это зависит от настройки ядра) на моей тестовой машине было две ошибки, относящиеся к файловой системе EXT4.


1
2017-12-13 10:42



@qdot, спасибо за подсказку. Я еще не могу попробовать, потому что что-то, что я попробовал, устранил проблему. Я «коснулся» файла (я отказался от восстановления данных), и теперь файл выглядит как обычный файл без содержимого. Когда я блуждаю по моим fs, я уверен, что я увижу больше этих (2 пока), после чего я попробую lsattr и опубликую результат. - bev
@qdot - ok здесь вывод: lsattr: операция не поддерживается При чтении флагов на blah.txt. НО, lsattr не возвращает никакой информации ни о каком файле в моей системе. В нем говорится: lsattr: несоответствующий ioctl для устройства. Показывая флаги в <каждом файле>. Таким образом, либо lsattr не работает на reiserfs, либо мой жесткий диск поврежден, но, похоже, работает нормально. Hmmmmm. Глядя на dmesg сейчас. - bev
ReiserFS: warning: is_tree_node: уровень узла 0 не соответствует ожидаемому 1 ReiserFS: sda3: warning: vs-5150: search_by_key: неверный формат, найденный в блоке 869576. Fsck? ReiserFS: sda3: warning: vs-13070: reiserfs_read_locked_inode: произошел сбой ввода-вывода, пытаясь найти данные статистики из [265071 265097 0x0 SD] ReiserFS: warning: is_tree_node: уровень узла 0 не соответствует ожидаемому 1 ReiserFS: sda3: предупреждение: vs-5150: search_by_key: неверный формат, найденный в блоке 869576. Fsck? - bev
Ях. Похоже, что существует проблема с конструкцией inode. Я снова запустил fsck. - bev
Ran fsck --check, который теперь говорит мне, что происходит много коррупции, и мне нужно запустить fsck -rebuild-tree. Итак, резерв моего раздела пару дней назад я побежал. Я вернусь к вам на результат. - bev


Ваша файловая система повреждена. Вероятно, fsck поможет.

edit: если вы не используете ReiserFS, в этом случае fsck может испортить его далее ...


7
2017-12-13 08:34



Это было первое, что я сделал. Он не возвращал плохих блоков. - bev
Это не может быть ничего. Пересмотрите эту возможность. Однако я просто заметил, что вы используете ReiserFS. Имейте в виду, что ReiserFS fsck может просто уничтожить вашу файловую систему. Это один из недостатков дизайна ReiserFS ... - jlliagre
Один из недостатков дизайна Reiserfs заключается в том, что запуск reiserfsck может привести к уничтожению файловой системы? Это полезно знать (после того, как, конечно, я запустил reiserfsck в своей файловой системе), я попытаюсь найти документацию по этому поводу. Lucky, я поддержал все 2 дня назад. Ох - и ты был прав. Я перезапустил fsck, и это показало мне много проблем. - bev
Из en.wikipedia.org/wiki/ReiserFS: Процесс восстановления дерева в fsck от ReiserFS вызвал большую критику: если файловая система настолько сильно повреждена, что ее внутреннее дерево непригодно, выполнение операции восстановления дерева может привести к повреждению существующих файлов или появлению новых записей с неожиданным содержимым - jlliagre
@jlligre - спасибо за ссылку. Довольно страшно. Я обдумываю свой следующий шаг. У меня есть весь раздел резервных копий. У меня есть причина полагать, что физический hd в порядке, текущая ситуация связана с тем, что я возился с 2 внешними hd после того, как я сделал резервную копию (хотя я не вижу, что я сделал, что вызвало это). Не могли бы вы предложить мне разбить раздел и форматировать с помощью ext3? thx для совета. - bev


chattr +i file делает файл полностью защищенным от записи, даже root. Это называется неизменным. Чтобы удалить или изменить, вы должны сначала изменить его на chattr -i file,


4
2017-12-13 07:50



спасибо за помощь, к сожалению, это не сработало. Вот что произошло: $> chattr -i blah.txt $> chattr: Permission denied при попытке стата blah.txt - bev