I'm running Redhat 5.2(x86_64) on a RAID5 array (hardware RAID card). I'm trying to backup some files to a SATA drive I have attached directly to the motherboard. So the backup is not occurring over the network, it's all happening on the same computer.

I have about 250GB of data to copy over to the SATA drive. I used the pax command as I remember reading somewhere that command was faster than doing it by cp. I used the pax command in the following format to do the copy (I need the file attributes and ownership to be preserved):

pax -rw -pe data/ /mnt/backupdrive

Copying over 250GB took a tremendously long time, over a couple days. Is that normal when data is just being copied from one drive to another on the same system? Is there a faster command I can use for performing this copy to an internal drive?


BTW, here's the benchmark times for my backup SATA drive:
hdparm -Tt /dev/hda1

/dev/hda1:
Timing cached reads: 26456 MB in 1.99 seconds = 13263.69 MB/sec
Timing buffered disk reads: 12 MB in 3.48 seconds = 3.45 MB/sec


Here's the number for the system's drive:

/dev/sdb1:
Timing cached reads: 26836 MB in 1.99 seconds = 13454.22 MB/sec
Timing buffered disk reads: 388 MB in 3.01 seconds = 129.11 MB/sec

The read-speed of hda1 looks appalling ... can you paste the full hdparm output?

hdparm /dev/hda

hda probably has not dma enabled. That can happen for a number of reasons, but the most common case is that the correct module is not being loaded for your IDE controller, hence you would be using generic IDE support, without DMA.

The hdparm -cdi /dev/hda output will be useful to diagnose this.

Thanks for the replies. The output for hdparm is below.

It looks like dma is off. I tried to turn it but I get an error. I've also included that below along with dmesg info about the device.

# hdparm /dev/hda

/dev/hda:
multcount = 0 (off)
IO_support = 0 (default 16-bit)
unmaskirq = 0 (off)
using_dma = 0 (off)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
geometry = 65535/255/63, sectors = 1465149168, start = 0



# hdparm -cdi /dev/hda

/dev/hda:
IO_support = 0 (default 16-bit)
using_dma = 0 (off)

Model=ST3750640AS, FwRev=3.AAJ, SerialNo=3QD0PP0Q
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=unknown, BuffSize=16384kB, MaxMultSect=16, MultSect=off
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=268435455
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2
AdvancedPM=no WriteCache=enabled
Drive conforms to: Unspecified: ATA/ATAPI-1 ATA/ATAPI-2 ATA/ATAPI-3 ATA/ATAPI- 4 ATA/ATAPI-5 ATA/ATAPI-6 ATA/ATAPI-7
* signifies the current active mode



# hdparm -d 1 /dev/hda

/dev/hda:
setting using_dma to 1 (on)
HDIO_SET_DMA failed: Operation not permitted
using_dma = 0 (off)



# dmesg | grep hda
hda: ST3750640AS, ATA DISK drive
hda: max request size: 512KiB
hda: 1465149168 sectors (750156 MB) w/16384KiB Cache, CHS=65535/255/63
hda: cache flushes supported
hda: unknown partition table
hda: hda1
hda: hda1
hda: status timeout: status=0xd0 { Busy }
hda: no DRQ after issuing MULTWRITE_EXT
EXT3 FS on hda1, internal journal
EXT3 FS on hda1, internal journal

When it's supported, it's on. That and the fact that it gives you an error means that you haven't enabled a correct driver for your chipset (or maybe it's so strange that it doesn't exist, but I doubt that nowadays).


I would require to take a look at your lspci output, as well
as your kernel config. You can post the lspci stuff here, as
for the kernel config, you can copy if from /proc/config.gz and
paste it into pastebin.com or some similar service, then paste
a link.

The requested output for lspci is below. I didn't find a /proc/config.gz file in RHEL 5.2, but I did find the /boot/config-2.6.18-92.el5 file which I think it what you are looking for? I uploaded it here: http://pastebin.com/m2074b2eb

BTW, the system is a Fujitsu TX300-S4 server, purchased earlier this year. Thanks again for looking into this.


# lspci
00:00.0 Host bridge: Intel Corporation 5000P Chipset Memory Controller Hub (rev 92)
00:02.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x8 Port 2-3 (rev 92)
00:03.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x4 Port 3 (rev 92)
00:04.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x4 Port 4 (rev 92)
00:05.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x4 Port 5 (rev 92)
00:06.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x8 Port 6-7 (rev 92)
00:07.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x4 Port 7 (rev 92)
00:10.0 Host bridge: Intel Corporation 5000 Series Chipset FSB Registers (rev 92)
00:10.1 Host bridge: Intel Corporation 5000 Series Chipset FSB Registers (rev 92)
00:10.2 Host bridge: Intel Corporation 5000 Series Chipset FSB Registers (rev 92)
00:11.0 Host bridge: Intel Corporation 5000 Series Chipset Reserved Registers (rev 92)
00:13.0 Host bridge: Intel Corporation 5000 Series Chipset Reserved Registers (rev 92)
00:15.0 Host bridge: Intel Corporation 5000 Series Chipset FBD Registers (rev 92)
00:16.0 Host bridge: Intel Corporation 5000 Series Chipset FBD Registers (rev 92)
00:1c.0 PCI bridge: Intel Corporation 631xESB/632xESB/3100 Chipset PCI Express Root Port 1 (rev 09)
00:1c.1 PCI bridge: Intel Corporation 631xESB/632xESB/3100 Chipset PCI Express Root Port 2 (rev 09)
00:1c.2 PCI bridge: Intel Corporation 631xESB/632xESB/3100 Chipset PCI Express Root Port 3 (rev 09)
00:1d.0 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #1 (rev 09)
00:1d.1 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #2 (rev 09)
00:1d.2 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #3 (rev 09)
00:1d.3 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #4 (rev 09)
00:1d.7 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset EHCI USB2 Controller (rev 09)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d9)
00:1f.0 ISA bridge: Intel Corporation 631xESB/632xESB/3100 Chipset LPC Interface Controller (rev 09)
00:1f.2 IDE interface: Intel Corporation 631xESB/632xESB/3100 Chipset SATA IDE Controller (rev 09)
00:1f.3 SMBus: Intel Corporation 631xESB/632xESB/3100 Chipset SMBus Controller (rev 09)
01:00.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Upstream Port (rev 01)
01:00.3 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express to PCI-X Bridge (rev 01)
02:00.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Downstream Port E1 (rev 01)
02:01.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Downstream Port E2 (rev 01)
08:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS 1078 (rev 03)
0b:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200e [Pilot] ServerEngines (SEP1) (rev 02)
0c:00.0 PCI bridge: Broadcom EPB PCI-Express to PCI-X Bridge (rev c3)
0d:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet (rev 12)
0e:00.0 PCI bridge: Broadcom EPB PCI-Express to PCI-X Bridge (rev c3)
0f:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet (rev 12)
[root@new-host-3 ~]#

Yes, as long as that's the kernel version that you are running (check with uname -r).

The first thing I have to ask you is: is there any reason why you are running such an old kernel? I would first try to update it to something newer, 2.6.29.x or 2.6.30.x.

If after that the problem is not solved (or you don't want to update for some reason), you will need to recompile the kernel. I would first try to disable the "generic IDE support", I *think* that the CONFIG_BLK_DEV_PIIX (which you have enabled) should support your chip. If it doesn't then the thing becomes slightly more complicated.

A solution would be to disable the IDE subsystem altogether, and use the newer PATA driver for your controller, which is enabled by the option CONFIG_ATA_PIIX. The problem here is *probably* that you have the IDE stuff compiled statically into your kernel, (option '*' in menuconfig), while the PATA stuff is compiled as a module, which means that it get's into scene later. The IDE generic driver is getting to handle the disk before PATA gets into scene.

I don't know if you have experience compiling your own kernel, so if all of this seems a bit cryptic to you, don't worry, it's easier than it sounds. Just ask for guidance and I will clarify whatever needs clarification.

If you already know how to compile the kernel, all you need to do to test this is to make sure that you disable the IDE system completely in your menuconfig, and then make sure that the PATA stuff is included *statically*, and not as a module (option '*', and not 'm' in menuconfig), into your kernel. That will save you the initrd pain and all that stuff.

in menuconfig, these are the options you need to mark:

One thing worth mentioning is that once you have succeeded and the PATA driver replaces the generic IDE driver, the dma will be on without any further setup. Another thing worth mentioning is that the drive will be named as a SATA/SCSI drive, which means that it will become sd<whatever> instead of hd<whatever>. Depending on your controllers, it might be named sda or sdb, this means that the other drive could change it's name as well (if this one becomes sda, the old sda will become sdb). This doesn't affect your bootloader settings, since that's out of the reach of linux, but it will affect your mount settings, which means that /etc/fstab will also need some additional setup, nothing complicated, but you might need to use a livecd (or another distro that you have installed) to be able to reach your fstab file and edit it if you can't boot from your redhat installation.

That drive with dma on should out an output rate of around 30-40mb/s, it all depends on the disk and the controller, but so you get an idea, which is a lot better than it is now.

This post is a bit chaotic and is only meant to give some general ideas rather than a concrete step-by-step guide so don't be scared by it.

I appreciate the detailed reply i92guboj. The system has no updates at all on it as we've adopted an approach of "if it's not broke..." Well something is broke as this thread illustrates so I'll have to fix it. I'll try the update route first, I haven't run any of the RHEL updates on it ever so perhaps a kernel update will solve this. If not, I'll look into recompiling the kernel. That's something I've always dreaded doing but hopefully it's not as hard as it sounds. Thanks again.

Very well, just give the update route a try.

If you can't get it to work ok still, then it will be time to learn a new thing. It shouldn't be so difficult, overall if you already have a working configuration as a base. Either way, come back and let us know how the thing goes.