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 fileutils-4.0-21 How reproducible: Always Steps to Reproduce: 1.see above 2. 3. 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.
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 (Stock 6.2)
Before I start, the problem is that you have data on a tape of a database you wish to restore.. correct? 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,... Cheers Phil =--=
The data is stored on tape with database tools, don't know the format (Database is SAPDB/ADABAS). 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 persists. 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/