Red Hat Bugzilla – Bug 40796
/bin/dd fails with 'cannot allocate memory' when using pipes
Last modified: 2008-08-01 12:22:51 EDT
Description of problem:
I'm trying to access a tape drive (DLT 7000) on a remote computer to
recover a database. A local pipe was created:
aubir3p2:sqdp01> ls -l /tmp/tapedev
prwxrwxrwx 1 sqdp01 sapsys 0 Mai 15 23:51 /tmp/tapedev
I start a background process to 'dd' the tape remotely and write into the
aubir3p2:sqdp01> rsh crmtest "/bin/dd if=/dev/st0 obs=8k conv=sync"
> /tmp/tapedev &
where "crmtest" is the machine the DLT is connected to and /dev/st0 is the
tape device on that machine.
When I now instruct the database to recover from this pipe, the remote
process on the machine terminates with
aubir3p2:sqdp01> rsh crmtest "/bin/dd if=/dev/st0 obs=65535 conv=sync"
/bin/dd: /dev/st0: Cannot allocate memory
0+0 records in
0+0 records out
Both systems are Compaq ProLiant servers running SAP R/3 on Kernel
aubir3p2:sqdp01> uname -a
Linux aubir3p2 2.2.19-6.2.1enterprise #1 SMP Mon Apr 9 22:36:08 EDT 2001
aubir3p2:sqdp01> rpm -qa | grep fileutils
Steps to Reproduce:
Actual Results: no remote restore is possible
Expected Results: should be possible to access a tape remotely
Without having this options it's currently not possible to continue our
project because a database restore is not possible --> Serverity High.
Since this works when using local files (dd if=/some/file obs=8k conv=sync
>pipe & dd if=pipe of=/copy/of/some/file), I think you're having a problem
with the st0 driver.
What SCSI controller are you using?
Did it ever work with older kernels ?
The DLT is connected to the on-board controller. Here's dmesg:
ncr53c8xx: at PCI bus 0, device 13, function 0
ncr53c8xx: 53c876 detected
ncr53c8xx: at PCI bus 0, device 13, function 1
ncr53c8xx: 53c876 detected
ncr53c876-0: rev 0x14 on pci bus 0 device 13 function 0 irq 9
ncr53c876-0: ID 7, Fast-20, Parity Checking
ncr53c876-1: rev 0x14 on pci bus 0 device 13 function 1 irq 10
ncr53c876-1: ID 7, Fast-20, Parity Checking
scsi0 : ncr53c8xx-3.4.1-20000726
scsi1 : ncr53c8xx-3.4.1-20000726
scsi : 2 hosts.
ncr53c876-1-<6,*>: FAST-10 WIDE SCSI 20.0 MB/s (100 ns, offset 15)
Vendor: QUANTUM Model: DLT7000 Rev: 2255
Type: Sequential-Access ANSI SCSI revision: 02
I never tried with older kernels.
If I should try with an older kernel, which one should I use?
2.2.17-14 would be a good test
This works fine in
[sqdp01@crmtest sqdp01]$ uname -a
Linux crmtest 2.2.14-5.0smp #1 SMP Tue Mar 7 21:01:40 EST 2000 i686 unknown
Before I start,
the problem is that you have data on a tape of a database you wish to restore..
the tape driver you need to use in in a remote machine.. correct?
before I continue, can you tell me what format this data is stored in? cpio,
tar, dump, raw, other,...
The data is stored on tape with database tools, don't know the format (Database
Since the database stores the data on the harddisk in 8k blocks I assume that
also this 8k blocks are stored on the tape.
You understood right, following scenario is given:
Machine with tape: crmtest running 2.2.14-5smp
machine with db (target) aubir3p2 running 2.2.19-6.2.1enterprise
I now did the following:
I started a shell with the apropriate user on aubir3p2 and executed
aubir3p2:sqdp01> rsh crmtest "/bin/dd if=/dev/st0 bs=512k" > /tmp/tapedev
So the machine is calling crmtest, dd'ing with a blocksize of 512k from the
tape writing that to the local (aubir3p2) pipe /tmp/tapedev. The database is
restoring from that tape with database tools.
If it's necessary I can give you remote access (ssh) to look further.
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases,
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/