Bug 40796 - /bin/dd fails with 'cannot allocate memory' when using pipes
/bin/dd fails with 'cannot allocate memory' when using pipes
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
i686 Linux
high Severity high
: ---
: ---
Assigned To: Arjan van de Ven
Aaron Brown
Depends On:
  Show dependency treegraph
Reported: 2001-05-15 18:45 EDT by Markus Doehr
Modified: 2008-08-01 12:22 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-30 11:39:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Markus Doehr 2001-05-15 18:45:15 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 
local pipe:

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" 
> /tmp/tapedev
/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 
i686 unknown

aubir3p2:sqdp01> rpm -qa | grep fileutils

How reproducible:

Steps to Reproduce:
1.see above

Actual Results:  no remote restore is possible

Expected Results:  should be possible to access a tape remotely

Additional info:

Without having this options it's currently not possible to continue our 
project because a database restore is not possible --> Serverity High.
Comment 1 Bernhard Rosenkraenzer 2001-05-17 08:07:23 EDT
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.

Comment 2 Arjan van de Ven 2001-05-17 08:12:24 EDT
What SCSI controller are you using?
Did it ever work with older kernels ?
Comment 3 Markus Doehr 2001-05-17 08:30:23 EDT
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?
Comment 4 Arjan van de Ven 2001-05-17 08:39:05 EDT
2.2.17-14 would be a good test
Comment 5 Markus Doehr 2001-05-17 14:53:24 EDT
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

(Stock 6.2)
Comment 6 Phil Copeland 2001-05-17 15:23:10 EDT
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,...


Comment 7 Markus Doehr 2001-05-17 15:34:54 EDT
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.

Comment 8 Bugzilla owner 2004-09-30 11:39:00 EDT
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/

Note You need to log in before you can comment on or make changes to this bug.