Interactive and tape drives

[Admin]

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