PROBLEM:
I can do multivolume cpio backups on tape, but then
I cannot restore them due to cpio problems.


SETUP:
cpio-2.4.2-12
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


DETAILS:
I use these commands:

Backup:
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.


Restore:
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
size,
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
wrote:
> 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
this:
| - 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