I have an external 3.5" USB 250Gb HDD which is showing symptoms of hardware problems (repeated /var/log/messages errors of "reset high speed USB device using ehci_hcd"). This was originally plugged in to my NSLU2 running Debian Etch. I have just installed Ubuntu Desktop 9.10 to a spare Pentium-3M laptop and was hoping to copy the contents of this HDD to a fresh drive. However, I cannot mount it even read-only; mount -o ro /dev/sde3 /mnt/disk fails, and the /var/log/messages error is "recovery required on readonly filesystem", "write access unavailable, cannot proceed". I cannot understand why mounting a disk read-only should require write access. Following advice I googled elsewhere, I tried running mke2fs -n /dev/sde3 to try to list the alternative superblocks - but once again I got the error that the device was read-only.

How can I go about accessing the data on this disk?

Thanks in advance for your assistance.

Nick

use dd to copy the disk image, then try to work on it

dd if=/dev/$DISK of=$HOME/diskimage

if you get read errors , dd can ignore them, keep reading the rest.

dd if=/dev/sde3 of=/new_backup/diskimage

terminated after 23Mb, which is not good for a 250Gb partition which was very nearly full.

I'm trying again with conv=noerror at the end.

Considering the read errors I'm getting, how do I go about mounting the disk image as a usable filesystem?

using loopback. as long as read errors are not on the some important block (like superblock). it should mount

Because ext3 is a journalling f/s, and you have a dirty journal. Without the journal committed you have (potentially) files that have been updated, but the updates haven't actually been written back to the file. I'd suggest you mount it for update - after it (hopefully successfully) runs the journal, remount as ro.

and don't forget to finish the dd, and work on the disk image. this is unix, it makes no difference.

Thanks for the suggestion, but mounting it read-only actually tries to open it read-write to replay the journal anyway - and my hardware errors mean that journal replay is not possible. I initially tried to mount it read-write but that failed, so I thought mounting it read-only should allow me to get the data off because that would mean the system wouldn't need to write to the physical disk.

I still think it is logically nonsense for a read-only mount option to require write access to the disk! Why can't it replay it in RAM so the actual disk isn't touched? I can easily add a terabyte of swap space if necessary. Seems like bad design to me.

Thanks for the help. It looks like the dd is going to take at least 12 hours at the current rate of progress. Before this thread goes cold - won't mounting the dd image as a read-only loopback device have the same problems about being unable to replay the journal as I do on the real file system? How do I go about avoiding that?

I can see you're getting frustrated with things but that kind of comment won't do you or anyone else any good.


Yes.


You don't. Make a copy of your disk image, loopmount the file, let kpartx figure out the partitions then run a dry run verbose fsck, then fsck. Fsck will replay the journal but may dump files in lost+found. Relocation makes it slightly harder to retrieve data from unallocated space but it's a trade-off. (An alternative could be to convert your dd image to a vmdk, add the disk to a VMware guest, snapshot it and make it non-persistent. This way you can run a fsck on bootup, grab files, and still have your image copy unaltered.) BTW there's tools like 'ddrescue' and dd_rescue' that may perform faster when facing disk errors.

Yes that is what I recall from my testing. As you hadn't mentioned it I presumed things may have changed since then.I've had this discussion elsewhere. I assume Ted is of the opinion that he won't hand over a non-verified filesystem to userspace. Seems reasonable to me.
As for doing it in RAM - how you going to do that if block device driver can't read the disk in the first place ?. Much better option - may not be faster, but deal with errors sanely. Which can't be said of "dd".

By "faster" I mean that by using 'dd_rescue' you're not forced to use a small block size by default as it figures out the largest block size to use itself and only uses a small block size when dealing with errors.

Removed