Win7 file copy slow from DVD

June 10, 2010 6:36 PM

Why is file copying from a DVD so slow in Win7?

I need to create a copy of a DVD (legit Windows Server 2003 install) on my HDD in order to slipstream some drivers because I don't have a floppy drive. I popped the DVD in the drive and after chugging away for a bit, Windows calculated I'd be waiting approximately four and a half hours while it transferred at 350KBps or so. I quit that and created an image file on my HDD (using imgburn) that I can copy the files out of. This ran at around 10,500 - 11,000 Kbps. Why was the windows file copy so slow?

posted by sanko to Computers & Internet (8 answers total)

In my experience, Windows often comes up with an utterly meaningless first guess for estimated file transfer times. I suspect it's taking its initial time reference from the first attempt at access to the source device, and for a DVD this does involve a certain amount of chugging and fooling about before the data actually starts to stream. I'd bet money that if you'd actually just let it get on with it, you wouldn't have been waiting anywhere near four hours.
posted by flabdablet at 7:16 PM on June 10, 2010

Never trust a Windows file transfer estimate. Just yesterday, I watched a 7GB network transfer. The initial estimate was ten minutes--then one day, two hours. Over the next two minutes, I watched as the progress bar inched past 90%. The transfer was then estimated for one day, eight hours. This number didn't go down until it was done, after a total of maybe three minutes.
posted by Phyltre at 7:29 PM on June 10, 2010

DVD and CDs really are the worst medium. At best you're getting something like 5 or so megabits per second average and depending on the quality of the media, burn, and reader it can be much less. Error correction slows things down considerably.
posted by damn dirty ape at 8:30 PM on June 10, 2010

You could have a slow drive. I have an internal BD drive in my computer and an external one connected by USB2, and the external drive reads BDs about twice as fast as the internal one.
posted by Chocolate Pickle at 8:57 PM on June 10, 2010

Copying lots of small files always results in slow transfer speed. There are way more file seeks than copying a single large file.
posted by wongcorgi at 10:02 PM on June 10, 2010

Also, this time is compounded by the fact that you're copying from an optical drive and if the media is scratched/dirty, it might be even worse.
posted by wongcorgi at 10:05 PM on June 10, 2010

Um, guys, a lot of you are missing the point that the poster is comparing vastly different speeds with the same disc in the same drive, so saying that "there might be scratches" or "optical drives suck" doesn't really cut it.

I agree with wongcorgi that the difference in types of IO is the main culprit. Creating an image file means purely sequential (linear) IO because you're just copying sectors without regard for the filesystem. Copying as files means more random IO because it involves reading for a short bit at one spot, seeking to another, waiting for the media to spin to the right spot, and continuing to read. All those things kill your throughput. Now as to whether that explains all of the different remains to be seen. It could be that the way the filesystem happened to be organized caused the beginning of the copy to involve lots of small files which would be the worst case scenario for random IO, which means that the time estimator would calculate a very slow overall speed, and that if you let it continue it would speed up once it got to copying larger files and the difference between the two speeds would be much less.
posted by Rhomboid at 1:50 AM on June 11, 2010

What Rhomboid said.

But also, the Windows File Copy progress bar is NOTORIOUSLY bad (and as a programmer, I can understand why... With IO operations like that, any estimations that you try to make of the amount of time it'll take are wild guesses, at best.

See XKCD's take on it.
posted by antifuse at 6:17 AM on June 11, 2010