I'm posting here because redhat/bugzilla moved my bug report
from cpio to kernel, so they think this is a kernel/scsi issue.
==
kernel 2.2.14, cpio-2.4.2-13 (rh61)
scsi_mod, aha152x, st as modules
SCSI controller: Adaptec AVA-1050
SCSI tape unit: Tandberg SLR2 525MB
PROBLEM:
I can do multivolume cpio backups on tape, but then
I cannot restore them due to cpio problems (maybe due to the kernel).
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
M�kisara, 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
Thanks.
--
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
