copying large files between filesystems

Mike Fedyk mfedyk at matchmail.com
Wed Jun 30 23:08:04 UTC 2004


Andrew Scott wrote:
> 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).

Ahh, you're using scsi?

Can you post excerpts from your kernel logs?

>> 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.

Sorry, this won't help with scsi... :(

>> 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!
> 

Actually byte by byte...

> 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?

run cmp (compare) on the two files, it will tell you where they are 
different.

>>> 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.
> 

Use IDE, then people might consider that... ;)

Mike





More information about the fedora-list mailing list