[TUHS] why does tar have the tape device hard coded into it and why is it mt1 instead of mt0

[TUHS] why does tar have the tape device hard coded into it and why is it mt1 instead of mt0

[Will Senn]

All,

In my exploration of v6, I followed the advice in "Setting up Unix - 
Seventh Edition" and copied v6tar from v7 to v6. Life is good. However, 
tar is using mt1 and it is hard coded into the source, tar.c:
char    magtape[]       = "/dev/mt1";

As the subject line suggested, I have two questions for those of you who 
might know:

1. Why is it hard coded?
2. Why is it the second device and not the first?

Interestingly, it took me a little while to figure out it was doing this 
because I didn't actually move files between v6 and v7 until today. 
Before this my tests had been limited to separate tests on v6 and v7 
along the lines of:

cd /wherever
tar c .
followed by
tar t
list of files
cd /elsewhere
tar x
files extracted and matching

What it was doing was writing to the non-existant /dev/mt1, which it 
then created, tarring up stuff, and exiting. Then when I listed the 
contents of the tarfile, or extracted the contents, it was successful. 
But, when I went to move the tape between v6 and v7, the tape (mt0) was 
blank, of course. It was at this point that I followed  Noel's advice 
and "Used the source", and figured out that it was hard-coded as you see 
above.

Thanks,

Will

[TUHS] why does tar have the tape device hard coded into it and why is it mt1 instead of mt0

[Clem Cole]

First, the device # should be usable from the command line, i.e.  tar cv0
foo

As for mt, it was written for the tape device and in those days most of us
had at least one 9-track device.    I have no memory of why Ken used mt1
not mt0.   Doug may know.

On Fri, Dec 11, 2015 at 5:27 PM, Will Senn <will.senn at gmail.com> wrote:

> All,
>
> In my exploration of v6, I followed the advice in "Setting up Unix -
> Seventh Edition" and copied v6tar from v7 to v6. Life is good. However, tar
> is using mt1 and it is hard coded into the source, tar.c:
> char    magtape[]       = "/dev/mt1";
>
> As the subject line suggested, I have two questions for those of you who
> might know:
>
> 1. Why is it hard coded?
> 2. Why is it the second device and not the first?
>
> Interestingly, it took me a little while to figure out it was doing this
> because I didn't actually move files between v6 and v7 until today. Before
> this my tests had been limited to separate tests on v6 and v7 along the
> lines of:
>
> cd /wherever
> tar c .
> followed by
> tar t
> list of files
> cd /elsewhere
> tar x
> files extracted and matching
>
> What it was doing was writing to the non-existant /dev/mt1, which it then
> created, tarring up stuff, and exiting. Then when I listed the contents of
> the tarfile, or extracted the contents, it was successful. But, when I went
> to move the tape between v6 and v7, the tape (mt0) was blank, of course. It
> was at this point that I followed  Noel's advice and "Used the source", and
> figured out that it was hard-coded as you see above.
>
> Thanks,
>
> Will
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> http://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151211/8384cbce/attachment.html>

[TUHS] why does tar have the tape device hard coded into it and why is it mt1 instead of mt0

[Will Senn]

On 12/11/15 4:31 PM, Clem Cole wrote:
> First, the device # should be usable from the command line, i.e.  tar 
> cv0 foo
>
> As for mt, it was written for the tape device and in those days most 
> of us had at least one 9-track device.    I have no memory of why Ken 
> used mt1 not mt0.   Doug may know.
>
Clem,

Thanks, that'll teach me to read the man pages more carefully even when 
the command is familiar in its modern form. Your tip about the device 
number caused me to check. Sure enough, it's in the documentation :). I 
am so impressed with the durability of the original documentation. These 
were written some 40+ years ago, and they're still amazingly useable by 
folks like me who have only worked with OSes created since the 1990's 
(of course, not entirely without help).

man tar
...
0,...,7   This modifier selects the drive on which the tape
                is mounted.  The default is 1.
...

-will
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151211/7e21278c/attachment.html>

[TUHS] why does tar have the tape device hard coded into it and why is it mt1 instead of mt0

[John Cowan]

Will Senn scripsit:

> Thanks, that'll teach me to read the man pages more carefully even
> when the command is familiar in its modern form. 

Note that if -f is not given, modern tars still default to the tape
drive, /dev/st0 on Linux or /dev/sa0 on *BSD.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
Barry thirteen gules and argent on a canton azure fifty mullets of five
points of the second,  six, five, six, five, six, five, six, five, and six.
        --blazoning the U.S. flag

[TUHS] why does tar have the tape device hard coded into it and why is it mt1 instead of mt0

[Random832]

On 2015-12-11, John Cowan <cowan at mercury.ccil.org> wrote:
> Will Senn scripsit:
>
>> Thanks, that'll teach me to read the man pages more carefully even
>> when the command is familiar in its modern form. 
>
> Note that if -f is not given, modern tars still default to the tape
> drive, /dev/st0 on Linux or /dev/sa0 on *BSD.

That depends on the tar. A lot these days default to stdin (or
stdout as appropriate to the operation). Many don't even support
the "drive number" option. OSX knows nothing of the options, and
Ubuntu's GNU tar says:

tar: Options '-[0-7][lmh]' not supported by *this* tar

GNU tar has the capability, but it's apparently not a very
well-used feature, since the ./configure script it ships with
has a bug in a sed command meant to convert e.g. "/dev/st0" to
"/dev/st" [prefix for 0-7 to be appended to].

Star switched in 1982, according to the author. And in any case
even when POSIX did define tar, it only said the default was
"system-dependent".

The only one I could find that keeps this alive is bsdtar
(libarchive) which apparently will even use something called
\\.\tape0 if compiled for Windows. But it doesn't actually
support the 0-7 options.

Well, that and OpenSolaris tar. Which apparently gets devices
_and_ blocking factors corresponding to arguments 0-7 from
/etc/default/tar:

> archive0=/dev/rmt/0		20	0
> archive1=/dev/rmt/0n		20	0
> archive2=/dev/rmt/1		20	0
> archive3=/dev/rmt/1n		20	0
> archive4=/dev/rmt/0		126	0
> archive5=/dev/rmt/0n		126	0
> archive6=/dev/rmt/1		126	0
> archive7=/dev/rmt/1n		126	0

(The third argument is a size parameter; you're supposed to use
it if you define one of the devices to be a floppy drive.)

[TUHS] why does tar have the tape device hard coded into it and why is it mt1 instead of mt0

[Doug McIlroy]

> I have no memory of why Ken used mt1 not mt0.   Doug may know.

I don't know either. Come to think of it, I can't remember ever
using tar without option -f. Direct machine-to-machine trasfer,
e.g. by uucp, took a lot of business away from magtape soon
after tar was introduced. Incidentally, I think tar was written
by Chuck Haley or Greg Chesson, not Ken.

Doug

[TUHS] why does tar have the tape device hard coded into it and why is it mt1 instead of mt0

[Mary Ann Horton]

Yeah, I just can't imagine using tar with the f option.  Even back in 
the day when I was writing 9 track magtapes with tar, it would be 
something like
     tar cvfb /dev/rmt0 10 .
to get tape blocks bigger than 512 bytes.  But we never had dectapes and 
I think they did their own blocking.

     Mary Ann

On 12/11/2015 06:09 PM, Doug McIlroy wrote:
>> I have no memory of why Ken used mt1 not mt0.   Doug may know.
> I don't know either. Come to think of it, I can't remember ever
> using tar without option -f. Direct machine-to-machine trasfer,
> e.g. by uucp, took a lot of business away from magtape soon
> after tar was introduced. Incidentally, I think tar was written
> by Chuck Haley or Greg Chesson, not Ken.
>
> Doug
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> http://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs

[TUHS] why does tar have the tape device hard coded into it and why is it mt1 instead of mt0

[Armando Stettner]

I recall using the -f option with the - for direction to/from  to move large hierarchies around and preserve metadata including creation/modify dats, owner/group, etc.

Sent from my iPad

> On Dec 12, 2015, at 10:54, Mary Ann Horton <mah at mhorton.net> wrote:
> 
> Yeah, I just can't imagine using tar with the f option.  Even back in the day when I was writing 9 track magtapes with tar, it would be something like
>    tar cvfb /dev/rmt0 10 .
> to get tape blocks bigger than 512 bytes.  But we never had dectapes and I think they did their own blocking.
> 
>    Mary Ann
> 
> On 12/11/2015 06:09 PM, Doug McIlroy wrote:
>>> I have no memory of why Ken used mt1 not mt0.   Doug may know.
>> I don't know either. Come to think of it, I can't remember ever
>> using tar without option -f. Direct machine-to-machine trasfer,
>> e.g. by uucp, took a lot of business away from magtape soon
>> after tar was introduced. Incidentally, I think tar was written
>> by Chuck Haley or Greg Chesson, not Ken.
>> 
>> Doug
>> _______________________________________________
>> TUHS mailing list
>> TUHS at minnie.tuhs.org
>> http://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs
> 
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> http://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs
> 

[TUHS] why does tar have the tape device hard coded into it and why is it mt1 instead of mt0

[Clem Cole]

Interesting  memories ... IIRC: workstations were really what caused /dev/*mt*
to stop being a standard name, so not screwing it down and using the -f
option made sense. But for a long time, since it was less typing on the 11s
and Vaxen, I would do:
           tar cvb0 20 mumble...
However, once we moved to the world of networking, the -f option became
important to me.
*i.e. *   tar cvf - mumble | rmt hosts ...

Also, the DEC drives had better buffering.  Large buffers became really
important with streaming versions of 9-track and of course for the later
QIC tapes.  So blocking became even more important and I quit doing that
function with tar itself and started to pipe tar through dd to do the
blocking to get really large blocks (like 256K or 1M).   Also, tools
appeared like "double dd" (aka ddd(1)) program that originally used a two
processes and pipe to coordinates the writes so that we could stream a
Cipher drive on a 10Mhz 68K (Masscomp box).

[Note to Will - you might to google for the original ddd or talk to me
offline, I bet I have it somewhere.  Its an interesting program to analyze
if you really want to get some insight on what you could do with UNIX even
on a "slow" computer by today's standards and without a lot of today's
fancy API's].


tjt rewrote dump(1) on RTU to use AST's and may have hacked dd too (I've
lost that version I fear).  In the mid, 80's I rewrote ddd to use threads
once kernel support for threading became available and I still use that
version today when I mess with tapes (which I do less and less, but have
been known to do when trying to recover old tapes).

Clem

On Sat, Dec 12, 2015 at 1:54 PM, Mary Ann Horton <mah at mhorton.net> wrote:

> Yeah, I just can't imagine using tar with the f option.  Even back in the
> day when I was writing 9 track magtapes with tar, it would be something like
>     tar cvfb /dev/rmt0 10 .
> to get tape blocks bigger than 512 bytes.  But we never had dectapes and I
> think they did their own blocking.
>
>     Mary Ann
>
>
> On 12/11/2015 06:09 PM, Doug McIlroy wrote:
>
>> I have no memory of why Ken used mt1 not mt0.   Doug may know.
>>>
>> I don't know either. Come to think of it, I can't remember ever
>> using tar without option -f. Direct machine-to-machine trasfer,
>> e.g. by uucp, took a lot of business away from magtape soon
>> after tar was introduced. Incidentally, I think tar was written
>> by Chuck Haley or Greg Chesson, not Ken.
>>
>> Doug
>> _______________________________________________
>> TUHS mailing list
>> TUHS at minnie.tuhs.org
>> http://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs
>>
>
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> http://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151212/8d2eebff/attachment.html>

[TUHS] why does tar have the tape device hard coded into it and why is it mt1 instead of mt0

[Lyndon Nerenberg]

On Dec 12, 2015, at 12:13 PM, Clem Cole <clemc at ccc.com> wrote:

> tjt rewrote dump(1) on RTU to use AST's and may have hacked dd too (I've lost that version I fear).  In the mid, 80's I rewrote ddd to use threads once kernel support for threading became available and I still use that version today when I mess with tapes (which I do less and less, but have been known to do when trying to recover old tapes).

Anyone recall when pump came into play?  What that a Plan9 thing?, or did it originate in Research UNIX.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151212/ac1e027e/attachment.sig>

[TUHS] why does tar have the tape device hard coded into it and why is it mt1 instead of mt0

[John Cowan]

Mary Ann Horton scripsit:

> But we never had dectapes and I think they did their own blocking.

Indeed.  A DECtape (aka microtape) was logically speaking a floppy disk
sliced into cylinders and then concatenated.  As a result it was possible
to rewrite any block without affecting later blocks, something not true
of conventional ("macro") tape.

My first system, a PDP-8/M, used a single DECtape drive as its system
"disk"; the second system, a PDP-8/A, used an 8-inch floppy.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
Don't be so humble.  You're not that great.
        --Golda Meir

[TUHS] TUHS] why does tar have the tape device hard coded into it and why is it mt1 instead of mt0

[Doug McIlroy]

Forget that I said, "I think that tar was written by Chuck Haley or Greg Chesson".
Ken confirms that he wrote it, for dectape.

Doug

[TUHS] why does tar have the tape device hard coded into it and why is it mt1 instead of mt0

[Diomidis Spinellis]

Interesting! Chuck Haley is also listed as the author of tar in "Life
with Unix" p. 31 (Libes and Resler, Prentice Hall,  1989).  I wonder
where that piece of misinformation came from and what other errors are
in the book.

Anyway, I corrected tar's authorship in the Unix history Git repo
https://github.com/dspinellis/unix-history-make/commit/d4d153afaa1b0e27deb678db40d7e3879d1a4e3d

Diomidis

On 12/12/2015 19:17, Doug McIlroy wrote:
> Forget that I said, "I think that tar was written by Chuck Haley or Greg Chesson".
> Ken confirms that he wrote it, for dectape.
> 
> Doug
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> http://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs
> 

[TUHS] why does tar have the tape device hard coded into it and why is it mt1 instead of mt0

[Norman Wilson]

/dev/makefile on the V7 distribution tape (or at least the
unpacked image I have that I believe to be same) says:

ht:
	/etc/mknod mt0 b 7 64
	/etc/mknod mt1 b 7 0
	/etc/mknod rmt0 c 15 64
	/etc/mknod rmt1 c 15 0
	/etc/mknod nrmt0 c 15 192
	/etc/mknod nrmt1 c 15 128
	chmod go+w mt0 mt1 rmt0 rmt1 nrmt0 nrmt1

According to /usr/sys/dev/ht.c, the minor device
number was used as follows:

minor(dev) & 07		slave unit number
minor(dev) & 070	controller unit number
minor(dev) & 0100	tape density: set == 800 bpi, clear 1600
minor(dev) & 0200	no-rewind flag

It takes some digging in the source code (and the PDP-11
Peripherals Handbook) to understand all this numerology.
In most of the code, minor(dev) & 077 is just treated as
a unit number (fair enough).  The use of 0200 appears only
as a magic number in htopen; that of 0100 only as a magic
number in htstart, and that only implied: the test is
not minor(dev) & 0100, but
	unit = minor(bp->b_dev) & 0177;
	if(unit > 077)

Not so bad when the whole driver is only 376 lines of code,
but it wouldn't have hurt to make it 400 lines if that
meant fewer magic numbers.

Anyway, what all this means is that /dev/*mt0 and /dev/*mt1
both actually meant slave 0 on TU16 controller 0, but mt0
was 800 bpi and mt1 1600 bpi.  Hence, I would guess, tar's
default to mt1.

My first exposure to the insides of UNIX was in the High
Energy Physics group at Caltech.  Some of our systems had
multiple tape drives and every drive supported multiple
densities, so we invented for ourselves a system like that
many other sites invented, with names like /dev/rmt3h to
mean the third tape drive at high density.  (Hence the
USG naming scheme of /dev/rmt/3h and the like--not that
we taught it to them, just that many places had the same
idea.)

Our world wasn't nearly as exciting as that of our neighbors,
across the building and three floors down, in the Space
Radiation Laboratory.  They had a huge room full of racks
of magtapes full of data from satellites, and many locally-
written tools for extracting the data so researchers could
work on it.  The hardware was an 11/70 with eight tape drives,
and at any given time at least half the the drives would be
spinning.  One of the drives was seven-track rather than
nine-track, because some of the satellite data had been
written in that format.

Fair disclosure: I had a vague memory that the `drive number'
in the device name had been recycled for other purposes,
but couldn't remember whether it was density or something
else.  (I'm a little surprised none of the other old-timers
here remembered that, but maybe I worked with tapes more than
them.)  But I had to dig into the source code for the details;
I didn't remember all that.  And I did have to climb up to the
high shelf in my home office for a Peripherals Handbook to
understand the magic numbers being stuffed into registers!

Norman Wilson
Toronto ON

[TUHS] why does tar have the tape device hard coded into it and why is it mt1 instead of mt0

[Lyndon Nerenberg]

On Dec 12, 2015, at 5:41 PM, Norman Wilson <norman at oclsc.org> wrote:

> Anyway, what all this means is that /dev/*mt0 and /dev/*mt1
> both actually meant slave 0 on TU16 controller 0, but mt0
> was 800 bpi and mt1 1600 bpi.  Hence, I would guess, tar's
> default to mt1.

At Athabasca University we had an SI9000 (if I remember the model number correctly) tape drive (vacuum column, no less!) hanging off the 785.  This was a triple-density 800/1600/6250 drive, and I forget what the controller was we had it connected to.  Installing new versions of Ultrix was always fun, because the I/O register that set the density didn't agree with what Ultrix expected the device to do.  We always had to do a little dance on the console to interrupt the installer, manually poke the correct value into a register on the tape controller to set the proper drive density, then continue the installer.  That was my first experience with having to directly frob the hardware on big iron.

Come to think of it, the first program I ever wrote that poked into a live running kernel was something I hacked together to work around a bug in the CTIX QIC tape driver.  If you had a process with the tape device open while the tape was rewinding (deliberately or implicitly) and sent it an interrupt, the process would hang forever.  This got annoying enough that I wrote a little hack that would go in and clear the busy bit in the device table entry, which was enough to let the holding process return from the system call it was stuck in.

Tape drives were magical beasts.  Mostly from the dark side ...

--lyndon

(Don't get me started about trying to get enough I/O throughput out of a 3B2 to make the 9track stream :-P)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151212/c0e4f3fa/attachment.sig>