PDA

View Full Version : How long can it be?


Heedyheed
09-15-2004, 09:16 AM
I'm currently running dd to copy my Tivo's 120gig Samsung SP1213N to another identical drive. I set the blocksize in dd to 32k and the two drives are on the same IDE channel (mistake maybe?)

So far it's been running for about 16 hours. Of course dd isn't the most communicative bit of software around, so I've no idea how much longer it's likely to take or, indeed, if it's just hung and will never finish.

Can anyone tell me how much longer it's likely to be. Tempted to try Ghost at this rate...

Thanks,

Mike

threadkiller
09-15-2004, 09:50 AM
whats DD out of curiosity??????

cause dos based proggies like ghost won't work, you need to use MFS tools. & follow hinsdales guide

Heedyheed
09-15-2004, 09:58 AM
I'm no expert, but I guess dd is a Linux copy utility. I chose to use dd because I wanted a complete clone of my Tivo's disk and it seemed the easiest way to get there.

17 hours and counting... :(

Mike

Mike B
09-15-2004, 10:03 AM
'dd' is a built-in linux tools which allows a sector-by-sector copy of one device to another. It is useful for making a direct copy of an HDD.

You may have got a slightly quicker copy by putting the two devices on different IDE channels, but not by much. Are both of the drives using ATA133, or are they runing at only 33 or 66 MBps?

What command line did you use?

threadkiller
09-15-2004, 10:04 AM
heres another thread on DD interesting reading
http://www.tivocommunity.com/tivo-vb/showthread.php?s=&threadid=192337

aerialplug
09-15-2004, 10:10 AM
16 hours sounds like a long time to me...

My dd from the original TiVo drive to a 120Gb took 6 hours 20 minutes.

I'm told that it can be quicker than this if you set up the system to use DMA. I haven't tried this however, as I only needed to backup my disk once and have no need to try this technique again.

Has anyone tried this/know if it makes a difference?

[edit: removed a link to a site that turned out to be irrelevant:o]

Heedyheed
09-15-2004, 10:46 AM
Panic over :)

It's just finished. It took just over 17 hours in total. I've checked that the drives are configured to use ATA133. The dd command line I used was one that I've seen quoted here a couple of times:-

dd if=/dev/hda of=/dev/hdb bs=32k conv=noerror,sync

Thanks to all for your help

Mike

tefster
09-15-2004, 02:00 PM
Putting the two devices onto different IDE channels should certainly help
speed things up.

I haven't tried any IDE settings tweakings in terms of TiVo disk work and the
mfstools boot CDs, but generally with Linux you can get huge magnitudes of
speed increase by; turning on DMA usage, changing interrupt masks, and
turning on multi-sector I/O - via hdparm.
http://usalug.org/phpBB2/viewtopic.php?p=33142 has some info on this, and
I do the above on my Linux servers, but as mentioned I haven't tried it when
doing TiVoish things.

poissony
09-15-2004, 02:02 PM
As someone who today has done a full backup of my failing Samsung drive, I'd heartily recommend not using dd but using dd_rescue instead. Took me around 3 hours plus and is better at dealing with errors. I startted off using dd but after 4 hours is stopped with a input/output error.

More info on dd_rescue here:

http://www.tivocommunity.com/tivo-vb/showthread.php?s=&threadid=190306&highlight=ddrescue

Heedyheed
09-15-2004, 05:14 PM
I'd heartily recommend not using dd but using dd_rescue instead

Yes, given the time that dd took to complete, I think I'll be using dd_rescue next time - if only because I understand it provides some sort of indication of progress. I was very close to hitting control-C on several occasions because I was convinced that it wasn't running...

Fortunately, the bad-block handling capabilities of dd wasn't an issue - I'd already checked that the drive was error-free.

Thanks again for your help

Mike

Maclynn
03-11-2006, 01:53 PM
I have just finished copying a 250gb drive that has no recordings on it using dd.
It took thirty hours, (I am very patient).
It appears to be OK with no errors showing.
Has anyone had one take longer than this.
Mike.