On Tue, 18 Jan 2005, Tape Help wrote:
> Ok, I have the debug info, with comments where needed.
> Thanks alot!
>
...
> # find home -depth|cpio -o --format=newc --block-size=128 -F /dev/st0
> 14:24:48 kernel: st0: Block limits 1 - 16777215 bytes.
> 14:24:48 kernel: st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8
> 14:24:48 kernel: st0: Density 40, tape length: 0, drv buffer: 1
> 14:24:48 kernel: st0: Block size: 0, buffer size: 32768 (1 blocks).
^
This shows that your drive is in variable block mode.
> 14:24:48 kernel: st: Succeeded to enlarge buffer to 65536 bytes (segs
> 1->9, 4096).
> 16:32:28 kernel: st0: Error: 8000002, cmd: a 0 1 0 0 0 Len: 65536
> 16:32:28 kernel: Info fld=0x0, EOM Current st09:00: sense key None
> 16:32:28 kernel: Additional sense indicates End-of-partition/medium detected
> 16:32:28 kernel: st0: Async write error (write) 7fffffff.
This is actually a 'magic error code' within st: the previous write did
see the EOM early warning but all data was written. The code 7fffffff is
later interpreted as succesful write and reported as such but the next
write then returns the EOM error.
Next I would expect to see a message telling that one filemark is written.
It can be done by the application but it is also automatically done when
the device file is closed at this point (i.e., after write). But ...
> 16:32:28 kernel: st0: Unloading tape.
at this point cpio ejects the tape and no filemark is written.
> 16:32:58 kernel: st: Buffer at c0310000 normalized to 32768 bytes (segs 9).
> # cpio ejected the tape and was waiting for another.
> # I hit <cntrl>c
> # I put the tape back in
> # cpio -i --only-verify-crc --list --block-size=128< /dev/st0
> 16:40:52 kernel: st0: Error: 8000002, cmd: 0 0 0 0 0 0 Len: 0
> 16:40:52 kernel: Current st09:00: sense key Unit Attention
> 16:40:52 kernel: Additional sense indicates Not ready to ready
> change,medium may have changed
> 16:40:52 kernel: st0: Block limits 1 - 16777215 bytes.
> 16:40:52 kernel: st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8
> 16:40:52 kernel: st0: Density 40, tape length: 0, drv buffer: 1
> 16:40:52 kernel: st0: Block size: 0, buffer size: 32768 (1 blocks).
> 16:40:52 kernel: st: Succeeded to enlarge buffer to 65536 bytes (segs
> 1->9, 4096).
> 18:45:58 kernel: st0: Error: 8000002, cmd: 8 0 1 0 0 0 Len: 65536
> 18:45:58 kernel: Info fld=0x10000, Current st09:00: sense key Blank Check
> 18:45:58 kernel: Additional sense indicates End-of-data detected
> 18:45:58 kernel: st0: Sense: f0 0 8 0 1 0 0 e
Now st encounters end of data and this is reported as read error.
My drive behaves in a slightly different way: it returns the same data but
it also sets the EOM bit. In this case the st driver interprets the
situation as normal end of data assuming that this is where the writing
application stopped writing.
> 18:45:58 kernel: st0: Tape error while reading.
> 18:45:58 kernel: st0: Rewinding tape.
> 18:46:07 kernel: st: Buffer at c0310000 normalized to 32768 bytes (segs 9).
> # cpio give this error: cpio: read error: Input/output error
>
So, your debugging data and my debugging data revealed what was happening
and why we had different results. It is debatable what is the basic
problem. The st driver is working as it has been designed to work but this does
not match the expectations of cpio. My opinion is that any application
should at least try to write a filemark at the end of each tape file and
not rely on certain behaviour of drives and drivers at the end of an
incomplete file. This is especially important because there is no common
standard for tape semantics.
The problem can be solved by either changing st semantics or cpio
behavior. Before changing st semantics I would like to be convinced that
the changed semantics is what all (most) other unix tape drivers use. Any
change of semantics can break other applications.
I will forward this analysis (with a preface) to the cpio maintainers.
--
Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
