root@rsiatl.UUCP (Admin) (10/27/89)
Regarding the continuing saga of tape backups on ISC 2.0.2 using the Wantek driver and drive. I posted a note which stated that cpio behaved badly on anything other than a dc-600 cartridge. I got these comments: From: (Michael Umansky) If the tape driver is intelligent enough to parse the status from the tape controller, it will report EOM as soon as the drive sees it. Any normal cpio will be able to handle the EOM, especially the Sys V.3.2 version of the cpio command. Once a cartridge tape drive sees the physical EOM marker/holes on the tape it will not allow any requests except REWIND or WRITE_FILE_MARK. The only way you will run it off the end of the catridge spool is by issuing continuous WFM commands to a non-rewind device. Only the cartridge drive knows the difference between DC300 and DC600 type cartridges and only for setting correct write current. misha -- -------------------------------------------------------------------------- And Pim Zandbergen supplied a patch to afio which contained a bug on its face and did not fix the problem after the bug was repaired. From: Pim Zandbergen: In all Unix System V implementations I know, the device driver fails to do the last write(2) and sets errno to ENXIO (no such device or address). cpio catches this error and will ask for the [patch mostly deleted] ! } else if (got < 0) { ! if (errno = ENXIO) <<---- This should be if (errno == ENXIO) ! next(O_WRONLY, "End of medium"); ------------------------------------------------------------------------------- To continue my exploration of the problem, I wrote the following short program designed to open the tape drive, streams data to it in 256k blocks and reports on each write. When it finds an abnormality, it tries a write again just to see what happens. char foo[256001L]; extern int errno; main() { int fh; long i; long written = 0L; long total = 0L; if ((fh = open("/dev/tape",O_WRONLY, 777)) == -1) { printf("\nCould not open tape\n"); exit(1); } for (i=0;i<=256000L;i++) foo[i]='*'; foo[256001L]=0; i=1L; while (1) { if (written = write(fh, foo, 256000L) == 256000L) { printf("\nWrite #%ld , total bytes = %ld", i++, total += 256000L); } else { printf("\nWrite failed, errno = %d, written = %ld\n", errno, written); printf("\nTrying again ... \n"); written = write(fh, foo, 256000L); printf("\nWritten = %ld\n", written); printf("\nerrno = %d\n", errno); close(fh); exit(1); } } } ------------------------------------------------------------------------- Here is the output of the program run against a 150 foot tape: Write #1 , total bytes = 256000 Write #2 , total bytes = 512000 [Boring data deleted] Write #64 , total bytes = 16384000 Write #65 , total bytes = 16640000 Write failed, errno = 0, written = 0 Trying again ... Written now = -1 errno = 6 (ENXIO, No such device) I was watching the console on another terminal. The tape had already hit the end of tape and started to rewind when write #64 was performed. Also note that errno is NOT set to ENXIO or any other value. On the console was the message: Streamer: End of tape. errno = ENXIO only happend after the SECOND write after the tape had hit the end. I'll admit that I know less about a QIC tape than I should but these results seem to be unequivical. If the errno value is used as an indication of end of tape, 2 writes could have occured after EOT. If the return value of write() is used, then one could have. I have read elsewhere in the documentation (sorry, could not find for this post) that a buffered tape device does not return a reliable EOT. This is echoed in the documents of AFIO. If I'm doing something wrong here or am mis-interpreting the results, then I'd appreciate informed comments specific to Interactive. Interactive only documents 2 ioctl calls for driver wt, "erase" and "retension". Have I missed something somewhere? Non-specific general unix comments are not appropriate here. Unless I see evidence to the contrary, it appears that byte counting is the only way to reliably backup multi-tape volumes. John
edhall@rand.org (Ed Hall) (10/28/89)
In article <387@rsiatl.UUCP> root@rsiatl.UUCP (Admin) writes: >I have read elsewhere in the documentation (sorry, could not find for this >post) that a buffered tape device does not return a reliable EOT. This >is echoed in the documents of AFIO. This is true for all UNIX systems I know of, including Interactive's: the buffered (block) version of a device will not return a reliable end-of-media. You must use the raw (character) device. It's easy to see why--the system can have several buffers already queued when the EOM hits. Even though the user successfully ``wrote'' those buffers, they'll never make it onto the tape. -Ed Hall edhall@rand.org
jgd@rsiatl.UUCP (John G. De Armond) (10/29/89)
In article <1989Oct27.184405.3493@rand.org> edhall@rand.org (Ed Hall) writes:
^This is true for all UNIX systems I know of, including Interactive's:
^the buffered (block) version of a device will not return a reliable
^end-of-media. You must use the raw (character) device. It's easy
^to see why--the system can have several buffers already queued when
^the EOM hits. Even though the user successfully ``wrote'' those
^buffers, they'll never make it onto the tape.
^
100% true. The problem is that the interactive wantek driver does not
supply a raw interface. I'm convinced I have to count bytes to
reliably handle multi-tape volumes.
John
--
John De Armond, WD4OQC | Manual? ... What manual ?!?
Radiation Systems, Inc. Atlanta, GA | This is Unix, My son, You
emory!stiatl!rsiatl!jgd **I am the NRA** | just GOTTA Know!!!