Как узнать, каким файлам принадлежат сбойные секторы?

diff -qr /catalogue1 /catalogue2

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

debugfs если ext2/3/4 команда icheck покажет inode

Как узнать, каким файлам

https://github.com/Salamek/ddrescue-ffile

каким файлам они принадлежат?

https://github.com/zkrx/rescue2path

Там несколько разделов, NTFS и ext4. Вот логи, как восстанавливал:

[root@localhost disk]# ddrescue -n /dev/sda /dev/sdb mapfile


Press Ctrl-C to interrupt
Initial status (read from logfile)
rescued:         0 B,  errsize:       0 B,  errors:       0
Current status
rescued:     1000 GB,  errsize:    188 kB,  current rate:   21561 kB/s
   ipos:     1000 GB,   errors:       2,    average rate:   51511 kB/s
   opos:     1000 GB

[root@localhost disk]# ddrescue -d -r3 /dev/sda /dev/sdb mapfile


Press Ctrl-C to interrupt
Initial status (read from logfile)
rescued:     1000 GB,  errsize:    188 kB,  errors:       2
Current status
rescued:     1000 GB,  errsize:    2560 B,  current rate:        0 B/s
   ipos:   990234 MB,   errors:       5,    average rate:      520 B/s
   opos:   990234 MB

[root@localhost disk]# ddrescue -d -r3 /dev/sda /dev/sdb mapfile


Press Ctrl-C to interrupt
Initial status (read from logfile)
rescued:     1000 GB,  errsize:    2560 B,  errors:       5
Current status
rescued:     1000 GB,  errsize:    2560 B,  current rate:        0 B/s
   ipos:   990234 MB,   errors:       5,    average rate:        0 B/s
   opos:   990234 MB

[root@localhost disk]# ddrescue -d -r3 /dev/sda /dev/sdb mapfile


Press Ctrl-C to interrupt
Initial status (read from logfile)
rescued:     1000 GB,  errsize:    2560 B,  errors:       5
Current status
rescued:     1000 GB,  errsize:    2048 B,  current rate:        0 B/s
   ipos:   990234 MB,   errors:       4,    average rate:        2 B/s
   opos:   990234 MB

[root@localhost disk]# ddrescue -d -r3 /dev/sda /dev/sdb mapfile


Press Ctrl-C to interrupt
Initial status (read from logfile)
rescued:     1000 GB,  errsize:    2048 B,  errors:       4
Current status
rescued:     1000 GB,  errsize:    2048 B,  current rate:        0 B/s
   ipos:   990234 MB,   errors:       4,    average rate:        0 B/s
   opos:   990234 MB

# Rescue Logfile. Created by GNU ddrescue version 1.5
#      pos        size  status
0x00000000  0xE68E869600  +
0xE68E869600  0x00000200  -
0xE68E869800  0x00137C00  +
0xE68E9A1400  0x00000600  -
0xE68E9A1A00  0x252414600  +

Спасибо за ссылку на скрипт. Буду пробовать

Пока я пытался посмотреть, какому inode-у принадлежит конкретный кластер, внезапно выяснилось, что у меня пропал /dev/sdb. Тот самый, на который я всё переносил. Система его вообще отказывается видеть, говорит что мой контроллер Silicon Image из 2005 года не может видеть двухтерабайтный винт. Хотя ранее он его прекрасно видел, и в dmesg писал название харда, и устройство для него спавнил. И о полном переносе терабайта данных отрапортовал бодро.

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

Жесть, хорошо хоть исходные данные на месте.

Возможно, на контроллере прошит старый BIOS, который не понимает 2-терабайтные жёсткие диски. Вот что пишет контроллер при запуске.

Sil 3512A SATARaid  BIOS Version 4.3.534
Copyright (C) 1997-2005 Silicon Image, Inc.

Press <Ctrl-S> or F4 to enter RAID utility

Самый новый биос, который я находил в интернете, имеет версию 4.3.84. Число 534 больше, чем 84, и поэтому я решил, что мой биос новее...

Смотрю, ты копировал с диска на диск? Без создания промежуточного образа. И если ты пытался потом работать с любым из этих дисков, когда оба подключены в систему. То для системы наличие двух дисков с одинаковыми разделами с одинаковыми файловым системами с одинаковыми идентификаторами — это кринж и педофилия, от которых надо немедленно избавиться. И может случиться всё что угодно. Лично я всегда через obraz.dsk перегоняю диски при копировании, чтобы такого не случалось.

Ты прав. Однако, сразу после копирования, система ещё не знает, что на /dev/sdb появились разделы, которых раньше не было.

Я обновил прошивку на устройстве. Теперь оно видит 2-терабайтный винч. Однако копированию помешало отрубание электричества на 97% прогресса.

print str(err)

Это, пожалуй, самое популярное проявление питона 2 при запуске под 3.

FileNotFoundError: [Errno 2] No such file or directory: ‘debugfs’

Это под обычным пользователем. Не перед тем как запускать под рутом, лучше просмотреть, нет ли там, случайно, каких-то вредностей.

Второй скрипт мне вообще не даётся. Ему, как я понимаю, нужен полный образ диска /dev/sda, а не раздела /dev/sda13. Буду мучить первый скрипт. Не знаешь как поправить?

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

Двойственный print в третьем питоне только функция: print ... –> print(...).

Там есть зависимость от модуля, который есть только для третьего питона

Однако копированию помешало отрубание электричества на 97% прогресса

Это печально ©

Но ведь существует опция, что бы с сохраненного места копирование начать, ЕМНИП.

Я уже всё перенёс снова. Успешно. Загружается, видится. Теперь мне нужно понять, какие файлы были повреждены на разделе /dev/sda13. Я сделал образ этого раздела. И у меня есть адреса повреждённых блоков. Теперь нужно понять, что это за файлы.

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

Хотя скрипт такой маленький, что после замены этого print, он, может, и работать будет.

Когда в dmesg появляется сообщение, что с какого-то сектора диска не удалось прочитать данные, становится интересно, а что же оттуда читали. И это можно сделать в 3 шага:

• fdisk -l –> пересчитать сектор на диске в блок на разделе.
• INODE = debugfs -R "icheck BLOCK_ON_PARTITION" PARTITION
• debugfs -R "ncheck -c INODE" PARTITION

Но вот если в этом месте был не файл, то debugfs не признаётся, кому принадлежат метаданные там.

Понял.

Гуглится что-то лишь для ntfs софт.

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

Решено

Помогла эта статья: https://github.com/timwhite/technicallytim/blob/master/content/disk-recovery-...

Утилиты: blkstat, ifind, istat, debugfs

Имена файлов:

/usr/lib64/python2.7/imaplib.py
/usr/src/linux-3.1.4-gentoo/drivers/staging/ath6kl/os/linux/.netbuf.o.cmd
/usr/src/linux-3.1.4-gentoo/drivers/staging/ath6kl/os/linux/hci_bridge.o

Грац.

Ну, теперь имена пакетов по названиях файлов надо найти :)

Это, по-идеи, проще)

Вкратце, история следующая. Был декабрь 2011 года. Я решил приоткрыть балкон, чтобы мороз -40 падал прямо на компьютер, который я поставил на подоконник. В комнате в итоге было очень холодно, и я туда не заходил убил комнатное растение - зато биткоинов при таком разгоне намайнилось на треть больше.

Вот кстати тема из тех дней: Ещё одна тема про утечки памяти в FireFox 9.0.1

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

На самом деле, я заметил это сразу, и оперативно поменял HDD на флешку с линуксом LiveUSB.

Я отключил хард, чтобы потом приобрести новый и скопировать всё с него, а пока что ограничился только копированием самого важного. Сначала не было денег, а потом забыл. И тут я подумал «прошло уже 10 лет, пора бы». И купил и перенёс.

Вчера сидел на старой системе, и такая ностальгия.

А растение потом ожило и снова стало расти. А ещё оказалось, что сбойных секторов на харде не так уж и много. Всего лишь 200 килобайт. Которые ddrescue успешно прочитал, осталось только 2 килобайта.

Что интересно, система, которой я последний раз пользовался в 2013 году, спокойно запустила последний Palemoon-gtk2. Там в минимальных требованиях - Glibc 2.17, GTK 2.24 и Glib 2.32. У меня не удовлетворял требованиям только Glibc 2.16, но ебилд с версией 2.17 уже лежал в старом portage, осталось только собрать.

Вот только не работают видео на сайте с мультиками, обидно. ffmpeg имеет версию что-то вроде 0.6. Наверно, можно пустить через флеш, если сайт это поддерживает...