Tape doesn't rewind after backing up with 'tar'

[Chris Torek]

In article <1325 at ndmath.UUCP> mahesh at ndmath.UUCP (Mahesh) writes:
>1) What is the difference between mt8 and rmt8 (in simple english)

The difference is not simple English.

`mt' devices are (normally) `block devices'; `rmt' devices are
`character devices'.  The labels simply describe how the Unix kernel
talks to the hardware.  `Character' or `raw' devices typically receive
requests from the kernel saying `please move B bytes of data to or from
address A in user space'.  The restrictions on A and B are few.
`Block' devices normally see requests saying `please move blocks of
data according to this kernel data structure'.  That structure defines
the offset, number of blocks (typically 512 or 1024 or 8192 or ...
bytes each), user- or kernel-space address, device, and so forth.  The
treatment of `raw' requests is almost entirely up to the device driver;
the treatment of `block' requests must conform to the demands of the
kernel buffer system.

Most tape drivers simply convert a `raw' request to a variation on
the `block' request, for which no offset (seek) will be acknowledged
and in which the byte count is less (or not) restricted.

>2) Why does the tape rewind after 'tar'ing to rmt8 and not after
>'tar'ing to mt8

Because the tape driver is telling it to do so.  (But read on.)

Typically, each tape device driver makes the following use of the
`minor device number' which you see when you use `ls -l':

	% ls -l /dev/mt8 /dev/rmt8
	brw-rw-rw-  1 root       7,   8 Jan 19 05:06 /dev/mt8
	crw-rw-rw-  1 root      19,   8 Mar  6 09:41 /dev/rmt8
				      ^
			     minor device number

Also, the name in /dev typically includes the minor device number.
/dev/rmt4 is device (19,4), for instance.

A number of people think this is a stupid naming scheme, and that
the names should be more like `/dev/tape/raw-tu78-0-at-6250-bpi'.
(I myself might use something like `/dev/tape/rtu78.0.6250' and
`/dev/tape/btu78.0.6250' for rmt8 and mt8 respectively.)

In this particular case (the VAX TU78 driver), the bits are used thus:

	bits 0..2:	unit number (0, 1, 2, 3).
	bit 3:		if set, suppress rewind on close; otherwise
			rewind on close.
	bit 4:		if set, use high density (e.g., 6250 bpi);
			otherwise use low density (e.g., 1600 bpi).

This encoding scheme mimicks the one used for the TU77 driver, which
mimicks that for the TS11 and TE?? and TU11 and ... tape drives,
all the way back to ancient history (V6 or V7 Unix on a PDP-11).

>3) What does the phrase "compatible with ordinary files" mean in
>[the manual]?

In essence, it means that you can seek.  The kernel arranges things
so that if you try to write one byte at position 1234 (and assuming
that the block-device block size is 1024 bytes), the tape driver is
instead asked to read block 1 (bytes 1024..2047).  After that works,
the kernel replaces byte 210 in that block (1024+210=1234) and asks
the tape driver to write block 1 again.

Whether this can and does work depends on both the hardware (which
must be capable of addressing individual tape blocks) and the software
(which must arrange for the hardware to do it).  Most 9-track tapes
can rewrite blocks, but need `extended gaps' to be able to do it
effectively (and even then there is a limit).  The original intent
of block tape devices was to allow them to be mounted read-only as
file systems; this places less stringent requirements on both hardware
and software, and is more likely to work (and did in Griff Smith's
original TU78 driver, but not in the one distributed with 4.3BSD).

>The system I have is a convex running BSD 4.2 ...

Actually, I imagine it is running Convex's version of Unix, *derived
from* 4.2BSD---4.2BSD runs only on VAXen.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at mimsy.umd.edu	Path:	uunet!mimsy!chris