Диск NTFS поврежден после небезопасного удаления из Windows 7

Question

Во-первых, некоторая информация о диске - это портативный жесткий диск USB 2.0 (PQI H560), один раздел на все 640 ГБ, NTFS. Используется почти исключительно в Linux (arch и ubuntu), но изначально отформатирован в Windows 7.

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

А теперь сам вопрос:

Сегодня я допустил ошибку, вынув свой переносной жесткий диск из системы Linux и вставив его в коробку Windows 7. Все работало хорошо, я взял фильм с диска, и он лежал бездействующим в течение часа или около того. После этого я вынул диск (забыл размонтировать:/) и вставил его обратно в свой Linux.

К сожалению получил следующую ошибку:

[49162.611858] mount.ntfs[15397]: segfault at 7fff19cb1fe8 ip 00007f9fca88de4e sp 00007fff19cb1fa0 error 6 in libntfs-3g.so.79.0.0[7f9fca87f000+42000]

Хорошо, поддержка Linux NTFS не слишком хороша, поэтому я вернулся к Windows, чтобы сделать скандиск или что-то в этом роде. Да, верно:

You need to format the disk in drive F: before you can use it.

Do you want to format it?

Нет не знаю

Щелкните правой кнопкой мыши -> Инструменты -> Проверить сейчас (вот чкдск, верно?):

The disk check could not be performed because Windows can't access the disk.

Возвращаясь к знакомому Linux, fdisk -l находит файловую систему NTFS, но я немного боюсь использовать fsck или ntfsfix .

Как я уже сказал, поддержка Linux NTFS хорошо, отсутствует. Возможно, попробую сделать dd раздела на другой диск и поэкспериментировать там, но в настоящее время у меня нет оборудования для этого.

Есть идеи, почему это так плохо? Я думал, что NTFS довольно долговечна.

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

Answer 1

Небезопасное удаление диска было вашим недостатком.

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

Кроме того, нет ничего плохого в Windows 7. Вы выполнили небезопасное удаление, так что это не вина Windows.

Answer 2

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

dd if=/dev/sdb bs=512k |lzma -7 -c - >ntfs.img.lzma

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

dd if=/dev/sdb bs=512k |pv |lzma -7 -c - >ntfs.img.lzma

Я только установил уровень сжатия lzma на 7, потому что 9 может работать вечно на более медленном процессоре. Как только это закончится, я рекомендую testdisk и его родственное приложение Photorec. Testdisk способен в определенной степени восстанавливать файловую систему ... Я сам этим не пользовался, однако знаю некоторых людей, которые обожают это. Photorec - последняя попытка восстановить все отдельные файлы, она ищет начальные и конечные точки логических данных известных типов файлов. Однако, хотя это может занять много времени, вы должны сначала попробовать ntfsfix. Если это полностью уничтожит что-либо, просто извлеките изображение:

unlzma -c ntfs.img.lzma |pv |dd of=/dev/sdb bs=512k

И, просто пару быстрых мыслей о том, что пошло не так, я говорю, не вините ни в одной из ОС, они обе сыграли одинаковую роль в нанесении ущерба. Он был грязным из-за нечистоты Windows os, и при попытке монтирования с поддержкой записи ntfs-3g он был еще более поврежден до такой степени, что windows больше не нравится. Это будет звучать немного странно, но посмотрите в конфигурации ядра, и поддержка записи ntfs по-прежнему помечена как экспериментальная и At-your-own-risk. Как бы я ни ненавидел Windows, я не могу винить это на этот раз. Что-то странное с ntfs: unclean umount из windows можно исправить из windows, unclean umount из linux можно исправить из linux. Пересечение линии с нечистым разделом ntfs обычно убивает это ... sry, только одна из тех вещей.

Answer 3

Ответом на эту проблему было окончательное восстановление, за исключением некоторых больших файлов (2 ГБ +), журналов и проблем с некоторыми жесткими ссылками (которые рассматриваются как дубликаты), это исправило это.

Кроме того, чем больше я смотрел из журнала, тем больше казалось, что проблема не в MFT, не в корне, по крайней мере. Некоторые вещи, которые были продублированы не одинаково, кажется, что диск был сбой при теневом копировании, и, возможно, были некоторые петли или другая действительно плохая структура в более глубокой части MFT. Просматривая логи, кажется, что все реализации os фатально провалились, под этим я подразумеваю segfaulting. Интересный журнал от MacOS X:

Interval Since Last Panic Report:  472 sec
Panics Since Last Report:          2
Anonymous UUID:                    D89B5624-FF95-48B5-8F55-0987EA2D2466

Sun Jun 26 18:02:46 2011
panic(cpu 0 caller 0x6e085e4a): "ntfs_map_runlist_nolock(): Called for $MFT/$DATA!\n"@/SourceCache/ntfs/ntfs-65.5/kext/ntfs_attr.c:245
Backtrace (CPU 0), Frame : Return Address (4 potential args on stack)
 ...
  Kernel Extensions in backtrace (with dependencies):
     com.apple.filesystems.ntfs(3.4)@0x6e05a000->0x6e0b9fff

BSD process name corresponding to current thread: mount_ntfs

А потом он умер.

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

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