Могу ли я смонтировать образ раздела, доступный только для чтения, в который записывается ddrescue?

Я восстанавливаю поврежденный диск.

Первые 2 прохода сделаны, но я хочу спасти больше данных, имея возможность просматривать уже закрытое изображение раздела, пока оно заполняется новыми данными с помощью ddrescue.

Я смонтировал файл изображения:

mkdir sda3.img
mount -o loop,ro /media/sdc3/sda3.img sda3.img

Я начал еще одну сессию по спасению:

ddrescue -d -r3 /dev/sda3 sda3.img sda3.logfile

Пока все хорошо, я могу просматривать образ, смонтированный через петлевое устройство, и ddrescue пишет в образ, не сообщая об ошибках вывода:

GNU ddrescue 1.17
Press Ctrl-C to interrupt
Initial status (read from logfile)
rescued:   330315 MB,  errsize:  12565 MB,  errors:     500
Current status
rescued:   332072 MB,  errsize:  10809 MB,  current rate:    5406 kB/s
   ipos:    76576 MB,   errors:     500,    average rate:    2150 kB/s
   opos:    76576 MB,    time since last successful read:       0 s
Retrying bad sectors... Retry 1

Может ли это привести к потере данных или другим проблемам?

linux mount ddrescue

— unfa
источник

В таких случаях файловые системы, поддерживающие CoW, великолепны. Я использую BTRFS; Я бы смонтировать копию и не беспокоиться. :)

— Kamil Maciorowski

Монтирование образа только для чтения (ro) должно, по крайней мере, помешать вашему монтированию и просмотру изменить изображение, и пока я gddrescueсчастлив продолжать записывать новые данные в изображение, я предполагаю, что оно может продолжать восстанавливать новые данные, ОК ...

Но если данные достаточно важны для восстановления, почему бы не подождать, пока не будет выполнено восстановление? Или остановите / приостановите восстановление, попробуйте ro mount, чтобы проверить его на несколько минут, затем продолжите восстановление?

Я сомневаюсь, что вы сможете очень успешно читать смонтированный образ во время его записи, особенно если добавлены новые области.

Во-первых, обычно существует дисковый кеш, который пытается прочитать с диска только один раз, а затем использовать кеш для чтения в будущем. Будучи смонтированным ro, он не ожидает смены диска, поэтому, вероятно, не заметит никаких изменений на лету.
И восстановленное изображение может иметь некоторые серьезные ошибки, которые могут даже не позволить его монтировать, и может быть исправлено при запуске fsck, но вы не можете создать fsckобраз, не разрушая текущее восстановление. И быть осторожными вы должны только копия восстановленного изображения, в случае , если что - то пойдет не так или становится хуже вас все еще есть «чистое» изображение , чтобы скопировать и повторить попытку с.fsckgddrescue
Чтение и запись в один и тот же файл в одно и то же время, скорее всего, замедлит оба процесса. Я не хотел бы делать восстановление данных медленнее, если восстанавливаемый диск ухудшается или полностью выходит из строя.

— Xen2050
источник

В дополнение к вышесказанному: «mount -o ro» фактически не запрещает всем доступ для записи на диск. Это в основном только предотвращает изменение файлов. Например, журнал может быть изменен (см., Например, здесь: rwmj.wordpress.com/2011/02/03/mount-o-ro-writes-to-the-disk ). Поскольку диск уже поврежден, я бы предпочел этого не делать (и даже позже, только когда-либо монтировать копии образа, создавать наложения и т. Д.)

— Вольфганг Ноихль

Эта статья использует "guestfish" для создания и монтирования образа диска, я думаю, что это какой-то инструмент виртуализации? Он говорит: «Возможно также, что он просто обновляет суперблок, чтобы пометить его как чистый», как если бы он автоматически делал fsckпервый шаг . Будет mountли самостоятельно делать какие-либо записи с ro? Я никогда не видел ничего для USB-накопителей (просмотр графиков записи устройства и проверка «измененных» времен ext), но все возможно, особенно ошибки

— Xen2050

Я уверен, что это mountсамо по себе, см. Самый конец этой статьи. Он утверждает, что это драйвер ext3 (который входит в игру во время mount) очищает журнал. Что происходит только в том случае, если файловая система была «грязной», но опять же, мы говорим о сбойных дисках, поэтому они, скорее всего, таковы: если это была сама guestfish, перемонтирование также должно изменить содержимое, нет?

— Вольфганг Ноихль

Все команды в этой статье используют guestfish, я предполагаю / надеюсь, что это просто причуда guestfish, что его mount сначала запускает fsck. Раньше я монтировал грязные файлы с помощью только mount, и если они достаточно плохие, монтирование не выполняется, автоматического fsck нет. Это было бы довольно серьезной ошибкой, если mount начал писать что-то, когда ему говорили, что он

— доступен

В то время как, mount -o roвероятно, блокирует большинство доступа для записи, может быть хорошей идеей не касаться диска в любом случае и не допускать изменения образа диска на уровне блочных устройств (см., Например, здесь ).

— Вольфганг Ноихль
источник