Can I mount read-only a partition image that is being written into by ddrescue?

1

I'm recovering a damaged drive.

The first 2 passes are done, but I want to rescue more data, while being able to browse the already closed partition image, while it is being filled up with new data by ddrescue.

I've mounted the image file:

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

I've started another ddrescue session:

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

So far so good, I can browse the image mounted through a loop device, and ddrescue is writing to the image, without reporting output errors:

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

Can this possibly cause any data loss or other problems?

unfa

Posted 2015-10-27T07:40:54.037

Reputation: 419

In such cases filesystems supporting CoW are brilliant. I use BTRFS; I would mount a copy and not worry. :) – Kamil Maciorowski – 2017-12-07T10:10:12.887

Answers

1

Mounting the image read-only (ro) should at least prevent your mounting & browsing from changing the image, and as long as gddrescue is happy to keep writing new data to the image I'm guessing it might keep recovering new data OK...

But if the data is important enough to want to recover, why not just wait until it's done the recovery? Or stop/pause the recovery, attempt a ro mount to check it out for a few minutes, then continue the recovery?

I doubt you'll be able to read the mounted image very successfully while it's being written to, especially any new areas added.

  • For one, there's normally a disk cache that tries to only read from a disk once, then use the cache for future reads. Being mounted ro, it's not expecting the disk to change, so probably won't notice any changes on-the-fly.

  • And, the recovered image may have some serious errors that may not even allow it to be mounted, and could be fixed by running fsck, but you can't fsck the image without ruining the in-progress recovery. And being cautious you should only fsck a copy of the recovered image, in case something goes wrong or gets worse you still have the "clean" gddrescue image to copy & try again with.

  • Reading from and writing to the same file at the same time is likely to slow down both. I wouldn't want to make data recovery any slower, in case the drive being recovered gets worse or fails completely.

Xen2050

Posted 2015-10-27T07:40:54.037

Reputation: 12 097

In addition to the above: "mount -o ro" doesn't actually prevent all write access to the disk. It basically only prevents files from being changed. E.g. the journal may be changed (see e.g. here: https://rwmj.wordpress.com/2011/02/03/mount-o-ro-writes-to-the-disk/). Since the disk is damaged already, I'd rather not do that (and even later, only ever mount copies of the image, create overlays etc...)

– Wolfgang Noichl – 2017-12-06T14:15:31.023

That article uses "guestfish" to create & mount a disk image, I think it's some type of virtualization tool? It says "It is possible also that it is merely updating the superblock to mark it clean" as if it were automatically doing a fsck first. Will plain mount on it's own do any writes with ro? I've never seen any for USB drives (watching device write graphs & checking ext's "modified" times), but anything's possible, especially bugs – Xen2050 – 2017-12-06T18:12:12.907

I'm sure it's mount itself, see the very end of that article. It claims that it's the ext3 driver (which comes into play duringmount) cleans up the journal. Which only happens if the filesystem was "dirty" but then again, we're talking about failing drives, so they likely are... If it was guestfish itself, re-mounting it should change the content as well, no? – Wolfgang Noichl – 2017-12-07T09:15:55.867

All the commands in the article use guestfish, I'm guessing/hoping it's just guestfish's quirk that it's mount runs a fsck first. I've mounted dirty ext's before with just mount, and if they're bad enough mount fails, no automatic fsck. That would be a pretty serious bug if mount started writing things when it's been told to be read-only – Xen2050 – 2017-12-07T16:35:55.863

0

While mount -o ro probably blocks most write access, it may be a good idea not to touch the disk in any case and prevent the disk image from being changed at block device level (see e.g. here).

Wolfgang Noichl

Posted 2015-10-27T07:40:54.037

Reputation: 101

Asked: 2015-10-27T07:40:54.037

Viewed: 827 times

Active: 2017-12-07T09:35:00.087