Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 4820

Summary: Cannot restore multivolume cpio tape backups
Product: [Retired] Red Hat Linux Reporter: giulioo
Component: kernelAssignee: Michael K. Johnson <johnsonm>
Status: CLOSED NOTABUG QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: 6.0   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2000-01-31 09:26:59 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description giulioo 1999-09-01 07:42:05 UTC
I can do multivolume cpio backups on tape, but then
I cannot restore them due to cpio problems.

kernel 2.2.12; scsi_mod, aha152x, st as modules
(it happened with rh6 stock 2.2.5 too)
SCSI controller: Adaptec AVA-1050
SCSI tape unit: Tandberg SLR2 525MB

I use these commands:

find /path|cpio -ovHcrc -O /dev/st0
- it starts to backup then it asks me for a 2nd tape with:
"Found end of tape.  Load next tape and press RETURN."
I insert the 2nd tape and the backups ends regularly with
the message about the blocks copied.

cpio -ivdumHcrc -I /dev/st0
- it asks me for the 2nd tape with:
"Found end of tape.  Load next tape and press RETURN."
- then asks me for a 3rd tape!!, with:
"Found end of tape.  Load next tape and press RETURN."
Since I have not a 3rd tape (the backup took 2 tapes only),
I simply press enter (_leaving_ the 2nd tape IN)
"cpio: read error: No medium found" (the 2nd tape is in).

Note that:
- The stuf restored is only 5/10k smaller than the original
very little but the restore is unreliable.
- the backup took very little of the 2nd tape (say 10MB).
- I even tried with -B 5120
- I tried with different tapes (3M), different controllers
(all ISA adaptec with module aha152x.o) and different tape
units (all Tandberg)

I found an article on dejanews regarding problems with
cpio  multivolume restore with kernels 2.0.x (cpio quits
as soon as it arrives at the end of the 1st tape with an
I/O error).
I found nothing regarding kernels 2.2.x.

===begin deja article on 2.0.x kernels
On Tue, Mar 24, 1998 at 11:26:10AM +0100, Stephane KLEIN
> But the restoring (cpio -i ..) fails at the end of the
first tape with a
> read IO error.

I think this is a known bug in 2.0.X. The following message
is from Kai
Mdkisara, maintainer of the SCSI tape driver:

| On Wed, 28 May 1997, Jan Echternach wrote:
| > There is a problem with taper not detecting the end of
tape. With my
| > SCSI DAT drive and kernel 2.0.30, read() returns 0 only
one time, and
| > all subsequent reads return EIO. It seems that ftape
returns _two_
| > times 0, which taper handles correctly.
| >
| ...
| >
| > Do 2.1.x kernels return two times 0? If so, should
2.0.30 also return
| > two times 0 at end of tape?
| >
| What should happen, according to the BSD semantics, is
| - at filemark, the first read returns 0 bytes, the second
read returns
|   data from the next file
| - at EOD, the first and the second read return 0 bytes,
the third returns
|   error (-1)
| i.e., 2.1.x operates correctly.
| The EOD behaviour was fixed at 2.1.20. In principle, it
should be fixed
| also at 2.0.31 but I think the risks are too big: fixing
EOD behaviour
| may break something else (the fix from 2.1.20 can't be
used directly).
|         Kai

===end deja article

Comment 1 Jeff Johnson 1999-12-17 18:46:59 UTC
This appears to be a kernel problem (although the fix may have to be in cpio)
so I'm changing the component to kernel ...

Comment 2 giulioo 2000-01-31 09:26:59 UTC
I contacted Kai Makisara (st driver author).
He told me the problem seems to be my scsi drives (all tandberg  TDC 41xx) that
have problems with writing and reporting the status of the tape when the end of
the tape is reached.

The solution, that works for me, is to disable async and buffer writes for the
st driver:
mt stclearoption async-writes
mt stclearoption buffer-writes

This options are disabled by default on other unix (dg-ux, interactive) so that
I had the problem on linux only.