File copy performance degredation.
 

Hello,

Here is the setup:

1. Using linux to repartition and install dual boot linux windows systems.
2. Part of the installation requires copying large .5 - 1.5 gig ms SQL database files.
3. The systems have varying hardware but all systems range from p2 300 to p3 700 's, with 2 harddrives.
4. The data copying is from one drive to another.
5. All of this work is done from a live cd. a remastered knoppix and also have tried gentoo. Kernel 2.4.22



The problem.

Under dos I can copy a 1.5 gig file from drive c: to d: in about 9 minutes.
Under linux copying from hda to hdX the best I can do is 17 minutes.

Here is what I have tried.
-cp -av
-rsync with just about every option available including disabling checksum.
-a modified tar and buffer combination.
-Different hard drives
-swap file no swap file
-hdparm - dma on and off


The symptom is:

-- Under linux, no matter which copy technique I try, the transfer rate starts out quick and slowly degrades until the copy is finished. It seems to work just fine under dos so it is hard to believe it is hardware. I have searched for hours and found a few obscure posts with the exact same problems and no resolution.

Oh yeah and under windows XP the file copy is about 5 min. All of this done on the same hardware. And both source and destination filesystems are fat32.

Man, I am looking for answers to the same issue... Very frustrating.

--Akshun J

The problem may be overhead due to the "foreign" filesystem.
I'd suggest trying "dd" but then you may run the risk of losing data to bad blocks on the target drive and verifying with md5sum would be time-consuming.
:confused:

Sorry, overlooked the gentoo bit...

Cheers,
Tink

linux is slow at windows filesystems. the same things happen on my fast machine. it takes drastically longer to copy the stuff to windows partitions than for linux filesystems. the bigger the file, the more performance degredation. i have found though, that some linux kernels can vary quite a bit on how fast they are at windows filesystems. try some different kernels is your best way to speed it up. i can copy a 2 gig partition with dd in 1 minute. a 2 gig file to a windows filesystem takes severeal minutes.

What is dd???

man dd




Cheers,
Tink

i just ran several tests between reiserfs 17 gig partition and a 10 gig fat32 partition, and was getting no difference in copy time. 1.5 gig and 2.0 gig files. i couldn't believe it. i just recently changed up my partitions, so maybe that had some effect. i'll try it on some other machines with different kernels and different size partitions later tonite and see what that does.

Thanks, although I had no prior knowledge it was already on my system.

It's part of fileutils/coreutils ... if you have cp, rm, mv, df ... you have dd ;)


Cheers,
Tink

The results are in, and there's a big suprise.

This is the size of the files. 4 1 gigers and several smaller files.
4831544 .

This is copying from reiserfs to fat32.

real 6m50.139s
user 0m0.138s
sys 0m45.655s

This is from fat32 to a different fat32 on the same drive. whoa!

real 21m10.319s
user 0m0.422s
sys 15m39.411s

This is from the second fat32 to the first reiserfs.

real 6m37.359s
user 0m0.425s
sys 0m54.931s

This is from reiserfs to another reiserfs.

real 6m46.019s
user 0m0.451s
sys 0m50.132s

apparently, in this situation, i could save 7 minutes on a fat32 to fat32 copy by instead doing a fat32 to reiserfs to fat32. That's messed up man.
fat32 to fat32 21 minutes
fat32 to reiserfs to fat32 13 and a half minutes.
and look at the cpu usage on the fat32 to fat32 copy.


these partitions were in the second half of a 180 gig western digital, and i was getting the time with bascially this.
time (cp -rf /1/zunder /2;sync)
time (cp -rf /2/zunder /3;sync)
time (cp -rf /3/zunder /1;sync)


that was kernel 2.4.23 with low latency patches i think.

this is 2.4.19-r5-gentoo.
reiser to fat32, fat32 to fat32, then fat32 to reiser. same files, same partitions.


real 10m37.843s
user 0m0.125s
sys 0m55.942s

real 24m18.013s
user 0m0.396s
sys 19m49.314s

real 9m11.983s
user 0m0.431s
sys 1m44.721s


i just redid it with kernel 2.6.0 that i had around. looks like it's been fixed.


real 6m43.167s
user 0m0.153s
sys 0m39.938s

real 7m39.745s
user 0m0.409s
sys 1m0.214s

real 9m29.201s
user 0m0.190s
sys 1m17.140s

wash, rinse and repeat

real 6m51.721s
user 0m0.165s
sys 0m41.565s

real 11m4.192s
user 0m0.360s
sys 1m3.128s

real 10m2.721s
user 0m0.176s
sys 1m18.210s

a little weirder, but not the same performance hit as 2.4.xx
yes, it's the same order as before. reiser to fat32, f32 to f32, then f32 to reiser. strangely inconsistant results, but i was trying to see about the difference between the fat32 to fat32 copy, and other results, and most of the difference is gone. compared to the 2.4.xx series. even though the actual time varies quite a bit, you'll notice that the system time needed is more consistant.


and camelrider, i don't see why you would have to worry about bad blocks with dd? do you mean copying a filesystem, with the whole partition? The errors would show up just like they would with a file copy.
and you could just copy files with dd using a script if you wished. something like
for i in * ;do dd if=/source/$i of=/destination/$i bs=experiment; done
you could experiment with different block sizes if you wanted. i've never tried that to see if i could make it faster than a normal copy would be.