On a Mandriva 2006.0 system (single PATA disk):
dump -0 -f /dev/null -f/dev/hda5
completed in 4:04 at 26419kB/sec, for 6295MB. This partition
holds everything linux on that system except /boot and swap.
On identical hardware, a system running Mandriva 2007.1
given the same command only moves around 5Mb/sec. I don't have
the exact number yet, as it's still crawling along, but when
I initially discovered this it was while piping through nettee,
and that metered the transfer rate at about 4.6MB/sec. (This was
over a 1000BaseT connection which has been clocked moving
data as fast as 100MB/sec, for instance from dd on the send side to
/dev/null on the receiver).
hdparm /dev/hda was the same on both systems.
hdparm -tT /dev/hda gives about the same rate on both systems.
There seems to be nothing else using up CPU time.
Both systems were running blackbox, a couple of rxvt terminals,
and nothing much else.
The 2007.1 system may be running ext3 and the 2006 ext2, but
I wouldn't have thought that would have mattered much.
"iostat 1" shows only read activity
"top" shows very little CPU time being consumed on the 2007.1 system
by dump.
I'm mystified, what could possibly cause dump to slow down so much???
Note that tar running on this same 2007.1 partition, over nettee to
another system (I was cloning systems) metered an overall transfer
rate of 20Mb/sec, which is close to what dump was delivering under
2006.0. So it isn't a slow disk per se, there's some issue sepecific to
dump.
Has anybody else seen this? Suggestions?
David Mathog
If finally finished after 1800 seconds. 4498KB/sec for
7911.29MB. I didn't round off that time, that's what the
program reported, and this may just be a coincidence but
that is exactly 30 minutes.
All dumps don't take 30 minutes, dump of the /boot partition only
took 2 seconds, at 3515 kBytes/sec for 6.87MB.
Regards,
David Mathog
dump -0 -f /dev/null -f/dev/hda5
Boot knoppix, do NOT mount /dev/hda5, result:
276 seconds, 27831 KB/sec, 7501.55MB
which is what it should have been in the first place.
Mount /dev/hda5 as /media/hda5, repeat the test, and
get exactly the same dump rate. So mounted versus not
mounted didn't matter, at least under knoppix.
cp `which dump` /media/hda2 #this is /boot for Mandriva
reboot
Bring up Mandriva 2007.1, 2.6.21.1 kernel
/boot/dump -0 -f /dev/null -f /dev/hda5
also slow! I didn't wait for it, but after it gave the "finished
in 26 minutes" estimate I bailed. So it isn't the Mandriva 2007.1
dump binary that's slow, since the Knoppix dump binary was fast
on knoppix but slow on Mandriva.
Maybe it's the 2.6.21.1 kernel? Reboot to kernel 2.6.17-14mdv
and run the command with the Mandriva dump:
289 seconds, 26578 KB/sec, 7501.07MB
Which fast again. Looks like it was the kernel that
caused this problem. Try again on 2.6.17-14mdv with the Knoppix
dump binary just to see if there really is any difference between
the two dump binaries. Nope, exactly the same time as before.
So somehow or other 2.6.21.1, at least as I have it configured, messes
up dump. The kernel .config file for 2.6.21.1 was from Linus's
version in cooker, the only thing I changed was the processor
option, which is now set to
CONFIG_MK8=y.
because these are Athlon64 processors.
Bizarre. I'll see if there's anything in the kernel lists about this.
Regards,
David Mathog
> I just discovered that dump on Mandriva 2007.1 is painfully slow.
>
> On a Mandriva 2006.0 system (single PATA disk):
>
> dump -0 -f /dev/null -f/dev/hda5
>
sorry for my ignorance about this... but what does this "dump" do?
i don't even have this command in my system...
regards
"dump" copies a file system to an archive. To copy back from the
archive use "restore". This particular dump is for ext2/ext3, there are
other ones for other file systems. Normally it is used to back up to
tape or to pipe to another location. In this case I was trying to
speed up a network copy. Tar worked, but since dump usually runs faster
than tar by taking advantage of its connections deep in the file system
I thought that might work better. However, rather than running faster,
or even as fast, it ran 5X slower, which was very surprising. Since it
seems to be kernel related I filed a bug report here:
http://bugzilla.kernel.org/show_bug.cgi?id=8636
Regards,
David Mathog
> "dump" copies a file system to an archive. To copy back from the
> archive use "restore". This particular dump is for ext2/ext3, there are
> other ones for other file systems. Normally it is used to back up to
> tape or to pipe to another location.
A backup utility...
thanks
ArameFarpado