Help recovering data from ext3 partition with hardware errors
Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Help recovering data from ext3 partition with hardware errors
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?
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.
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.
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.
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.
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.
and don't forget to finish the dd, and work on the disk image. this is unix, it makes no difference.
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 still think it is logically nonsense for a read-only mount option to require write access to the disk! (..) Seems like bad design to me.
I can see you're getting frustrated with things but that kind of comment won't do you or anyone else any good.
Quote:
Originally Posted by vatachino
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?
Yes.
Quote:
Originally Posted by vatachino
How do I go about avoiding that?
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.
Last edited by unSpawn; 01-10-2010 at 06:08 PM.
Reason: //More *is* more.
Thanks for the suggestion, but mounting it read-only actually tries to open it read-write to replay the journal anyway
Yes that is what I recall from my testing. As you hadn't mentioned it I presumed things may have changed since then.
Quote:
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.
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 ?.
Quote:
BTW there's tools like 'ddrescue' and dd_rescue' that may perform faster when facing disk errors.
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.