Andrew Scott wrote:
I'm currently on Fedora core 2 with a 2.6.6 kernel. I'll have to try unarchiving to another filesystem. I'm runnnig badblocks on the drive right now. I've freed up enough space on the drive to uncompress in place, but that failed with I/O erros. Then I tried the bzip2recover program with absolutely horrible results as it creates over 2000 9K bzip2 files representing each 9k block in the archive on the drive which was so taxing on the drive that it caused it cough and spit.
Hi Mike,
Thanks for your thoughts.
Gah! Immediately run "mount mnt -o ro" (replace "mnt" with your mount point or device file).
You don't want to be writing to this drive *at all* if you're trying to recover data from it!
Good advice. The disk isn't currenlty mounted and I'm running badblocks on it in read-only mode writing the output to a file. Interesting side note: the output file has been created but no bad blocks show up in it yet -- does badblocks only write on exit to the output file? Otherwise, perhaps it's just the drive controller or the SCSI card that are throwing errors and the data is safe and sound (oh, I hope this is true).
Any ideas how to do a really slow read from a drive that might prove more accurate (less taxing) on the hardware? I've tried dd and am now thinking about resorting to running strings on the device and piping it to another filesystem, but that will probably still have errors in the resulting file.
Yeah, run
hdparm -d0 /dev/drive
Excellent idea. I'll do this once badblocks finishes (looks like another hour). Though hdparm /dev/sda doesn't really return much along the lines of configurable options, I'll have to try this none-the-less. Thanks.
That will turn off dma access to the drive which will slow access to the drive, and your entire system in general, but that's what you want right now...
and then:
dd bs=1 if=your-file-to-recover of=file-on-a-different-drive
Also, excellent idea. I was trying to read the filesystem blocksize of 4K. Totally stupid, I should go bit by bit!
I'll try these things next. Thanks for your thoughts. Excellent suggestions.
this will copy your file one byte at a time, creating more processing overhead which will slow you down.
Obviously, I don't know of any tools that rate limit file copying, except for maybe rsync, but I'm not sure about that either.
I emailed the guys at Namesys (reiserfs headquarters in Oakland, CA). They have a standing offer of "Ask any questions for $25". I sent them $25 and asked them a question. Hans Reiser got back to me as well as another employee, both with good suggestions. They suspected the hardware immediately. They made one really keen suggestion: if the bit count is identical on the original as the copy (when copied to another filsystem), but the md5sums are different, then try and run bindiff on the two files and use a binary editor to toggle the differing bits, with the goal of a correct md5sum match. I imagine this will the last thing
that's nice, but don't try that on the entire 2gb file, split it up first...
Good idea but how can I tell the split up files are actually good copies?
I try before sending the disk off for disk recovery.
Anyway, thanks a lot for your time and thoughts. What a pain in the ass.
Yep, anyone wonder why people like RAID?
Support your local student.
-Andrew
Mike
