Re: TK50, was: Re: [TUHS] Ultrix Tape: Block Size?

2018-10-18 Thread Warner Losh via cctalk
On Thu, Oct 18, 2018 at 7:23 AM Paul Koning via cctalk <
cctalk@classiccmp.org> wrote:

>
>
> > On Oct 18, 2018, at 4:31 AM, Christian Corti via cctalk <
> cctalk@classiccmp.org> wrote:
> >
> > On Wed, 17 Oct 2018, Clem Cole wrote:
> >> As Paul W pointed out correctly, the TK50 and its children in the DLT*
> >> family all used a fixed format 512 byte *blocks on the tape*.This
> >
> > And that is wrong. The TK50 clearly uses variable block sizes. For
> example, have a look at a RSX11 or VMS tape: ...
>
> Different point.  You're talking about the host programming interface;
> Clem was talking about the physical representation of the data on the
> tape.  Clearly it's easy to accept random-length blocks from the host and
> translate them to a sequence of 512 byte blocks on the media.  SIMH is an
> example of how that is done: it stores tape images as a count field plus
> data, laid down in a disk file that internally consists of a sequence of
> fixed length (512 bytes, traditionally) sectors.
>

Although they may be on the tape in some funky way, there's a higher layer
in the protocol stack that imposes block length, and if that's not properly
honored, the tapes written for Ultrix won't work when read back. You can't
write weird block lengths and expect the applications that read it
downstream to work. I have a vague memory of lecturing one of the
hydrologists I worked for in college on this point when they were sloppy
with their reading / writing of a TK50 with their water flow data on it...
The code fix, which I wound up doing, was easier than explaining this
concept to the hydrologist who, while he knew finite difference code better
than I ever learned, had trouble understanding record boundaries  In
the end, though, we got a larger disk so we could stage / unstage multiple
runs of data at once and then used VMS' BACKUP to save them to tape... The
TK50's were a *LOT* faster when the only job on the system was BACKUP since
they could stream and none of the other OS activity could get in the way...

Warner


Re: TK50, was: Re: [TUHS] Ultrix Tape: Block Size?

2018-10-18 Thread Paul Koning via cctalk



> On Oct 18, 2018, at 4:31 AM, Christian Corti via cctalk 
>  wrote:
> 
> On Wed, 17 Oct 2018, Clem Cole wrote:
>> As Paul W pointed out correctly, the TK50 and its children in the DLT*
>> family all used a fixed format 512 byte *blocks on the tape*.This
> 
> And that is wrong. The TK50 clearly uses variable block sizes. For example, 
> have a look at a RSX11 or VMS tape: ...

Different point.  You're talking about the host programming interface; Clem was 
talking about the physical representation of the data on the tape.  Clearly 
it's easy to accept random-length blocks from the host and translate them to a 
sequence of 512 byte blocks on the media.  SIMH is an example of how that is 
done: it stores tape images as a count field plus data, laid down in a disk 
file that internally consists of a sequence of fixed length (512 bytes, 
traditionally) sectors.

paul



Re: TK50, was: Re: [TUHS] Ultrix Tape: Block Size?

2018-10-18 Thread Christian Corti via cctalk

On Wed, 17 Oct 2018, Clem Cole wrote:

As Paul W pointed out correctly, the TK50 and its children in the DLT*
family all used a fixed format 512 byte *blocks on the tape*.This


And that is wrong. The TK50 clearly uses variable block sizes. For 
example, have a look at a RSX11 or VMS tape:


# mtdump AQ-RAE30-01.tap
Processing input file AQ-RAE30-01.tap
Processing tape file 1
Obj 1, position 0, record 1, length = 80 (0x50)
Obj 2, position 88, record 2, length = 80 (0x50)
Obj 3, position 176, record 3, length = 80 (0x50)
Obj 4, position 264, record 4, length = 80 (0x50)
Obj 5, position 352, record 5, length = 80 (0x50)
Obj 6, position 440, end of tape file 1
Processing tape file 2
Obj 7, position 444, record 1, length = 2048 (0x800)
Obj 8, position 2500, record 2, length = 2048 (0x800)
Obj 9, position 4556, record 3, length = 2048 (0x800)
Obj 10, position 6612, end of tape file 2
Processing tape file 3
Obj 11, position 6616, record 1, length = 80 (0x50)
[...]
Processing tape file 5
Obj 21, position 7328, record 1, length = 9216 (0x2400)
[...]
Processing tape file 8
Obj 363, position 3061188, record 1, length = 2048 (0x800)
[...]
Processing tape file 62
Obj 2370, position 19735716, record 1, length = 32256 (0x7E00)
[...]


Christian


Re: TK50, was: Re: [TUHS] Ultrix Tape: Block Size?

2018-10-17 Thread Clem Cole via cctalk
I took most of this off line, but I'll try to close down the discussion, so
we can get back to TUHS history.

Please be careful of your wording as it is easy to get confused
particularly if you never used the original 1/2" tape system you might not
understand the actual terms.  The term for reading Read and Write I/O Sizes in
a user program are different than tape block sizes (or as they were
originally referred LRECL - Logical Record Length).

As I said to Paul K, I sadly know way more about the minutia of tapes that
I really should admit [I broke in during the 60s using 7-track tapes on the
IBM Mainframes which really date me and I remember the 5-track tapes on one
of the systems, but I never personally used it].


On Wed, Oct 17, 2018 at 2:14 AM emanuel stiebler  wrote:

>  Longer blocks, too (2k or so) which would make any buffering issues more
> severe.
>


*Your user program read/wrote with 2K or more using DMA reads or writes but
it wrote 512 byte 'blocks.'*

As Paul W pointed out correctly, the TK50 and its children in the DLT*
family all used a fixed format 512 byte *blocks on the tape*.This
cannot be changed.   The tape format is handled by the tape controller
microcode and all of the blocks on all the streamers (DLT, 1/4, 1/2", 4mm
and 8mm) that I know about were fixed at 512 byte, although the OS could
write multiple (N) blocks at a time to the tape controller which will will
write as N blocks on the tape.

This was different from 1/2" parallel 7 and 9-track tape which was actually
had variable size 'blocks' in the writes and the tape format.  Since the
terminalogy was defined (by IBM) for 5/7/9 track drives, we still use that
terminology.

The trick is that streamer** format write* (which is bit seral):
 <512 bytes of serial data
[blk1]><512 bytes of serial
data[blk2]>.<512 bytes
of serial data>[blkn]

The key is that there are no inter-record gaps (IRG) between the  and < frames when recording on
a streamer.   BTW: they usually use a serpitine scheme - starting with the
center of the tape and moving outwards in a circular pattern - IIRC down on
tape end and up on tape start -- but that's fuzzy in my memory and I'm at
work so I can not look in any of the controller books  have at home.  If
you lose the bit stream on input (data under run), the tape controller
backs up the tape and when it starts to write again, it goes over the last
block trailer and start its new write at the end of it.   For instance the
original 1/4" QIC format wrote 4 passes, then later when the recording head
got better, it wrote 9 passes and then even more, but in the newer formats
(and withe better media) the head was smaller.

Also remember that EOT is handled different in the streamer formats from
1/2" 7/9 track and IIRC EOT can even differ between the different streamer
formats.

If you look at 1/2" parallel 7/9-track (which is where the terms and basic
concepts originate) 9-track has a 'inter-record gap' between the last
block's trailer and the next block's header.  When IBM originally defined
that 7 and 9 track formats (whch ANSI later codified), these gaps are
defined so that the there is time to start and stop the motors (somewhere,
I have a very old IBM document from the late 60s that describes this very
well using IBM terms like LRECL and DASD - direct access storage device ;-)

The key difference from a streamer tape is that the IBM LRECL or logicial
record size, could (and did) vary ***.  But to try to keep the amount of
wasted space (*i.e.* least amount of inter-record gaps), different programs
use different 'block size' and some formats (like ANSI labeled tapes) the
block size (LRECL) can vary within the tape itself.

Also, I don't think I ever knew why, but for some reason IBM's tape
utilites tended to like LRECL 10240 and 20480.   Since many of us UNIX
folks came from IBM and Multics, we also used the same sizes (*i.e.* 20b or
10240 8 bit bytes) - it was reasonably efficent (we got 150M per
traditional 2400" 1/2 tape at 6250 BPI - you could get 1/3 more space when
3M created a 3600" that fit in the original 1/2" reel) .

Thus the on-tape format of 1/2" (which is parallel encoding and one pass
over the tape):
   ..
[if the last last 'file' on the tape a second]
Note:   LRECL BYTES of BLK1 did not have to be the same as  much less 

Thus concept (and term) of 'tape blocks' was born.  Also note be careful
the term 'file' has specific meaning to a tape.  DEC started to use the
term 'save set' to disamiguated it BTW.   A tape 'file' N tape blocks,
followed by an a EOT mark.Thus, two adjacent tape marks actually
delinated end of recorded data in the tape. Thus in 7/9 track formats when
a new file is written the last  is backed up over and data
frame writing starts over writing the second  after the last


So ...   what this all means is that from the OS side, you start a DMA on X
blocks and then let the tape controller read or write it.  No matter the
number of blocks

Re: TK50, was: Re: [TUHS] Ultrix Tape: Block Size?

2018-10-17 Thread Paul Koning via cctalk



> On Oct 17, 2018, at 10:50 AM, Ethan Dicks via cctalk  
> wrote:
> 
> On Wed, Oct 17, 2018 at 8:15 AM emanuel stiebler via cctalk
>  wrote:
>> there were
>> TK50Z as an external drive, on "SCSI"
> 
> I have one - for a MicroVAX 2000.  I rarely used it.
> 
>> TK50 on QBUS with an TQK50 controller which really didn't stream to often
> 
> We had one in the 1980s.  You are right.  It didn't.

I wonder if that was a VAX-specific issue.  It streamed fine on J-11 based 
PDP11 systems running RSTS.  While most VAXen have faster CPUs than PDP-11s, 
that doesn't necessarily carry over to I/O.  

paul



Re: TK50, was: Re: [TUHS] Ultrix Tape: Block Size?

2018-10-17 Thread Ethan Dicks via cctalk
On Wed, Oct 17, 2018 at 8:15 AM emanuel stiebler via cctalk
 wrote:
> there were
> TK50Z as an external drive, on "SCSI"

I have one - for a MicroVAX 2000.  I rarely used it.

> TK50 on QBUS with an TQK50 controller which really didn't stream to often

We had one in the 1980s.  You are right.  It didn't.

> TK50 on QBUS with an TQK70 controller, which doubled the memory of the
> TQK50, which was capable of streaming ...

Ooh!  That works?  I might have to nab a TQK70 for that MicroVAX II I
have (the one we had at work in the 1980s.  I got it when the company
folded).

Mostly, really just need to image any tapes I have more than write new
tapes, presuming the media hasn't degraded too much in the past 30
years.

-ethan


TK50, was: Re: [TUHS] Ultrix Tape: Block Size?

2018-10-16 Thread emanuel stiebler via cctalk
On 2018-10-16 20:37, Paul Koning via cctalk wrote:
> 
> 
>> On Oct 16, 2018, at 1:23 PM, William Pechter via cctalk 
>>  wrote:
>>
>> DEC Tape II was the serial driven TU58.
>> The TK50 was CompacTape or something like that.  It was the predecessor of a 
>> number of square tapes...
>>
>> See DLT on Wikipedia https://en.m.wikipedia.org/wiki/Digital_Linear_Tape
>>
>> Bill

> I used DLT on RSTS systems, with a Qbus interface.  Those were modest speed 
> hosts and buses, but I never remember data late or overrun issues, and we 
> drove those tapes quite hard in full time streaming mode for backup and 
> software distribution.  Longer blocks, too (2k or so) which would make any 
> buffering issues more severe.

Just few words here, as I'm not sure anymore we are talking about the
same thing ...

there were
TK50Z as an external drive, on "SCSI"
TZ30 internal drive, on "SCSI", using TK50 tapes
TK50 on QBUS with an TQK50 controller which really didn't stream to often
TK50 on QBUS with an TQK70 controller, which doubled the memory of the
TQK50, which was capable of streaming ...




Re: [TUHS] Ultrix Tape: Block Size?

2018-10-16 Thread Paul Winalski via cctalk
On 10/16/18, William Pechter  wrote:
> DEC Tape II was the serial driven TU58.
> The TK50 was CompacTape or something like that.  It was the predecessor of a
> number of square tapes...
>
> See DLT on Wikipedia https://en.m.wikipedia.org/wiki/Digital_Linear_Tape
>
My mistake.  Yes, I was thinking of the TU58, a most miserable device.

-Paul W.


Re: [TUHS] Ultrix Tape: Block Size?

2018-10-16 Thread Paul Winalski via cctalk
On 10/15/18, Clem Cole  wrote:
> #$%^ - they >>weren't<< like DECtape from a reliability standpoint ...
> ᐧ
The original DECtape was extremely reliable.  Not so the TK50.
Calling it "DECtape II" was an insult to the original DECtape.  The
problem wasn't so much the drive itself, but the controller.  In an
effort to reduce costs, DEC used a controller that had insufficient
buffering capability for a streaming, block-replacement tape device
such as the TK50.  TK50s were prone to both data-late and overrun
errors.

The block size is almost certainly 512 bytes.

-Paul W.


Re: [TUHS] Ultrix Tape: Block Size?

2018-10-16 Thread Clem Cole via cctalk
But Paul's comment is still right on - the controller for both was a 1MHz
i8085 and just could not keep up.
I hated both .. its' too bad DEC refused to use QIC.   They did eventually
use 4mm DAT on an SCSI (and actually OEM'ed the drive from HP it turns
out).   The 8mm [Exabyte Unit] was from CSS and many of us in UNIX land had
them on our Alpha's - Tru64 supports as a 'latent' device - but the
politics of the day were TK-50 and TK-70 was the DEC official drive.

It's interesting until DEC sold off the team and DLT  to Quantum, it was
not very popular except at VMS sites since the Unix world knew that the
SCSI driver had full support for the standard devices.   To Quantum credit,
they redid the controller (put in a 68K IIRC) and life got much better.

But it was always way more expensive than QIC, 4 or 8 mm.

Clem
ᐧ

On Tue, Oct 16, 2018 at 1:23 PM William Pechter  wrote:

> DEC Tape II was the serial driven TU58.
> The TK50 was CompacTape or something like that.  It was the predecessor of
> a number of square tapes...
>
> See DLT on Wikipedia https://en.m.wikipedia.org/wiki/Digital_Linear_Tape
>
> Bill
>
> -Original Message-
> From: Paul Winalski 
> To: Clem Cole 
> Cc: The Eunuchs Hysterical Society , cctalk@classiccmp.org
> Sent: Tue, 16 Oct 2018 13:14
> Subject: Re: [TUHS] Ultrix Tape: Block Size?
>
> On 10/15/18, Clem Cole  wrote:
> > #$%^ - they >>weren't<< like DECtape from a reliability standpoint ...
> > ᐧ
> The original DECtape was extremely reliable.  Not so the TK50.
> Calling it "DECtape II" was an insult to the original DECtape.  The
> problem wasn't so much the drive itself, but the controller.  In an
> effort to reduce costs, DEC used a controller that had insufficient
> buffering capability for a streaming, block-replacement tape device
> such as the TK50.  TK50s were prone to both data-late and overrun
> errors.
>
> The block size is almost certainly 512 bytes.
>
> -Paul W.
>


Re: [TUHS] Ultrix Tape: Block Size?

2018-10-16 Thread Clem Cole via cctalk
On Tue, Oct 16, 2018 at 12:57 PM Paul Winalski 
wrote:

> The block size is almost certainly 512 bytes.
>
Which is what I said - the block siize is set by the HW.
But ... the issue is trying to get the TK-50 to stream.  Hence the
traditional unix: dd ibs=64K obs=XXX | tar xvfp -  trick.

This will tell the driver to read upto 128 blocks in one DMA and then pump
the bits into tar a 'XXX block' at a time (which is is usually 20b for
tar/cpio/dump et al and Ultrix obey's).
ᐧ


Re: [TUHS] Ultrix Tape: Block Size?

2018-10-16 Thread Ethan Dicks via cctalk
On Tue, Oct 16, 2018 at 1:49 PM Paul Koning via cctalk
 wrote:
> > On Oct 16, 2018, at 1:23 PM, William Pechter via cctalk 
> >  wrote:
> >
> > DEC Tape II was the serial driven TU58.
> > The TK50 was CompacTape or something like that.  It was the predecessor of 
> > a number of square tapes...
> >
> > See DLT on Wikipedia https://en.m.wikipedia.org/wiki/Digital_Linear_Tape
>
> DLT is something entirely different from "DECtape II"... DLT is fast, 1/2 
> inch tape, serpentine recording.  It's the direct ancestor of a whole series 
> of cartridge tapes of ever increasing capacity.

Yes.  There's DECtape (TU55/TU56), there's DECtape II (TU58), and
there's "CompacTape" (TK50/TK70) which developed into DLT III and so
on to LTO, etc.

The carts for original CompacTape and DLT are the same size.  The
drives are not of identical reliability.  TK50 drives jammed and had a
variety of physical problems.  Even when they were working, their
performance was affected by the systems they were attached to.  In
particular, they are a streaming technology from an era when low-end
systems couldn't feed them fast enough to keep streaming, so in the
case of the TK50, capacity was always listed as "up to 95MB per tape"
because on writes, if there wasn't data in the buffer, the tape
wouldn't just stop but you'd get a gap until there was enough data, so
your capacity was lower.  For reads, it would have to back up a long
ways, spin back up to speed and begin reading where it left off,
substantially slowing down read performance.

By the time DLT III came out, machines were faster and, AFAIK, the
hardware buffering was better so you didn't have the same problems.
Having cut a few hundred DLT III tapes 15 years ago, I found the tape
drives to be absolutely solid.  Over the next 10 years we had an
every-other-year upgrade/migration because our capacity needs grew
rapidly and the cost per drive stayed about the same.  I think they
were on LTO2 when I left, in a 200 tape/4 drive jukebox.

The short version of this is: TK50s were a PITA then, and they still are.

-ethan


Re: [TUHS] Ultrix Tape: Block Size?

2018-10-16 Thread Paul Koning via cctalk



> On Oct 16, 2018, at 1:23 PM, William Pechter via cctalk 
>  wrote:
> 
> DEC Tape II was the serial driven TU58.
> The TK50 was CompacTape or something like that.  It was the predecessor of a 
> number of square tapes...
> 
> See DLT on Wikipedia https://en.m.wikipedia.org/wiki/Digital_Linear_Tape
> 
> Bill
> 
> -Original Message-
> From: Paul Winalski 
> To: Clem Cole 
> Cc: The Eunuchs Hysterical Society , cctalk@classiccmp.org
> Sent: Tue, 16 Oct 2018 13:14
> Subject: Re: [TUHS] Ultrix Tape: Block Size?
> 
> On 10/15/18, Clem Cole  wrote:
>> #$%^ - they >>weren't<< like DECtape from a reliability standpoint ...
>> ᐧ
> The original DECtape was extremely reliable.  Not so the TK50.
> Calling it "DECtape II" was an insult to the original DECtape.  The
> problem wasn't so much the drive itself, but the controller.  In an
> effort to reduce costs, DEC used a controller that had insufficient
> buffering capability for a streaming, block-replacement tape device
> such as the TK50.  TK50s were prone to both data-late and overrun
> errors.

DLT is something entirely different from "DECtape II" -- that is a little 
rubber band driven cartridge, extremely slow and extremely lousy.  DLT is fast, 
1/2 inch tape, serpentine recording.  It's the direct ancestor of a whole 
series of cartridge tapes of ever increasing capacity.

I used DLT on RSTS systems, with a Qbus interface.  Those were modest speed 
hosts and buses, but I never remember data late or overrun issues, and we drove 
those tapes quite hard in full time streaming mode for backup and software 
distribution.  Longer blocks, too (2k or so) which would make any buffering 
issues more severe.



Re: [TUHS] Ultrix Tape: Block Size?

2018-10-16 Thread William Pechter via cctalk
DEC Tape II was the serial driven TU58.
The TK50 was CompacTape or something like that.  It was the predecessor of a 
number of square tapes...

See DLT on Wikipedia https://en.m.wikipedia.org/wiki/Digital_Linear_Tape

Bill

-Original Message-
From: Paul Winalski 
To: Clem Cole 
Cc: The Eunuchs Hysterical Society , cctalk@classiccmp.org
Sent: Tue, 16 Oct 2018 13:14
Subject: Re: [TUHS] Ultrix Tape: Block Size?

On 10/15/18, Clem Cole  wrote:
> #$%^ - they >>weren't<< like DECtape from a reliability standpoint ...
> ᐧ
The original DECtape was extremely reliable.  Not so the TK50.
Calling it "DECtape II" was an insult to the original DECtape.  The
problem wasn't so much the drive itself, but the controller.  In an
effort to reduce costs, DEC used a controller that had insufficient
buffering capability for a streaming, block-replacement tape device
such as the TK50.  TK50s were prone to both data-late and overrun
errors.

The block size is almost certainly 512 bytes.

-Paul W.


Re: [TUHS] Ultrix Tape: Block Size?

2018-10-15 Thread Clem Cole via cctalk
#$%^ - they >>weren't<< like DECtape from a reliability standpoint ...
ᐧ

On Mon, Oct 15, 2018 at 5:00 PM Clem Cole  wrote:

> Be careful, TK-50 is different than 9-track.  It's a streamer tape like
> QIC, 4mm and 8mm.   The blocking is done under the covers by the HW and the
> blovk size if just how a DMA is done.  I recommend that you pre-fetch the
> read with dd or double-dd setting ibs=64k, obs=20b and conv=sync and pipe
> the output to the reader (tar/cpio or the like) [if that fails try
> obs=1b].   This should work well as can (TK-50 overall suck - don't set
> your hopes high on anything with them -- they were DECtape from a
> realiabilty standpoint, they were different from the reset of the world,
> the performance was poor and they were expensive).
>
> Anyway, by using dd or the like a front end, it will allow the read
> streamer to read as fast as it can.  The problem is that the way it works
> under the cover does not shine with traditional UNIX I/O.  BTW: ibs of
> anything more than 64K on a VAX (or PDP-11) will not help because of the
> dma size on the Unibus caps DMA read/writes at 64K.   On a PMAX or (under
> Tru64 on a Alpha), you can try using really large ibs sizes depending on
> your physical memory size.
>
> BTW: What will help the most is actually finding a copy of the old
> double-dd program (from the UUNET archives) which forks off two child
> procees to perform the actual I/O and alternates between the two processes
> via pipe between them and controller - so one dd process is reading when
> the other dd process is writing.  [It used to be called: ddd before the
> Gnu guys grabbed that name for the debugger].   The command line might be
> something like:   ddd ibs=64k obs=20b | tar xvpf -
>
> FWIW:  I wrote a version of a fast dd years ago that used pthreads and a
> semaphore that I should still have kicking around.   At one point when I
> was dealing with streamer tapes for backup, I definitely ran it on Tru64
> and FreeBSD, but  I've forgotten where Ultrix fell.
> ᐧ
>
> On Mon, Oct 15, 2018 at 4:01 PM Warren Toomey  wrote:
>
>> All, I received this request from Matthew who isn't subscribed to either
>> the TUHS or cctalk lists. He knows how to read the lists archives. Many
>> thanks for any help you can provide.
>> Cheers, Warren
>>
>> - Forwarded message from Matthew Whitehead -
>>
>> Date: Mon, 15 Oct 2018 08:25:39 -0400
>> From: Matthew Whitehead
>> Subject: Ultrix Tape Blocks
>>
>>Warren,
>>  I wonder if you can give me a referral. I want to install Ultrix-32
>>on my MicroVAX II using the ancient TK-50 tape drive. I know the tape
>>files are on your archive, but I need to know the block size for each
>>of the many files; it can vary a lot.
>>Who might be able to help me with this?
>>Matthew Whitehead
>>
>> - End forwarded message -
>>
>


Re: [TUHS] Ultrix Tape: Block Size?

2018-10-15 Thread Clem Cole via cctalk
Be careful, TK-50 is different than 9-track.  It's a streamer tape like
QIC, 4mm and 8mm.   The blocking is done under the covers by the HW and the
blovk size if just how a DMA is done.  I recommend that you pre-fetch the
read with dd or double-dd setting ibs=64k, obs=20b and conv=sync and pipe
the output to the reader (tar/cpio or the like) [if that fails try
obs=1b].   This should work well as can (TK-50 overall suck - don't set
your hopes high on anything with them -- they were DECtape from a
realiabilty standpoint, they were different from the reset of the world,
the performance was poor and they were expensive).

Anyway, by using dd or the like a front end, it will allow the read
streamer to read as fast as it can.  The problem is that the way it works
under the cover does not shine with traditional UNIX I/O.  BTW: ibs of
anything more than 64K on a VAX (or PDP-11) will not help because of the
dma size on the Unibus caps DMA read/writes at 64K.   On a PMAX or (under
Tru64 on a Alpha), you can try using really large ibs sizes depending on
your physical memory size.

BTW: What will help the most is actually finding a copy of the old
double-dd program (from the UUNET archives) which forks off two child
procees to perform the actual I/O and alternates between the two processes
via pipe between them and controller - so one dd process is reading when
the other dd process is writing.  [It used to be called: ddd before the Gnu
guys grabbed that name for the debugger].   The command line might be
something like:   ddd ibs=64k obs=20b | tar xvpf -

FWIW:  I wrote a version of a fast dd years ago that used pthreads and a
semaphore that I should still have kicking around.   At one point when I
was dealing with streamer tapes for backup, I definitely ran it on Tru64
and FreeBSD, but  I've forgotten where Ultrix fell.
ᐧ

On Mon, Oct 15, 2018 at 4:01 PM Warren Toomey  wrote:

> All, I received this request from Matthew who isn't subscribed to either
> the TUHS or cctalk lists. He knows how to read the lists archives. Many
> thanks for any help you can provide.
> Cheers, Warren
>
> - Forwarded message from Matthew Whitehead -
>
> Date: Mon, 15 Oct 2018 08:25:39 -0400
> From: Matthew Whitehead
> Subject: Ultrix Tape Blocks
>
>Warren,
>  I wonder if you can give me a referral. I want to install Ultrix-32
>on my MicroVAX II using the ancient TK-50 tape drive. I know the tape
>files are on your archive, but I need to know the block size for each
>of the many files; it can vary a lot.
>Who might be able to help me with this?
>Matthew Whitehead
>
> - End forwarded message -
>


Re: [TUHS] Ultrix Tape: Block Size?

2018-10-15 Thread Warner Losh via cctalk
I'm glad you corrected because when they worked, they were awesome. When
they didn't, life had a lot of swearing in it... And when I was sysadmin
for the MicroVAX II that had them, I swore like a sailor

Warner

On Mon, Oct 15, 2018 at 3:04 PM Clem Cole  wrote:

> #$%^ - they >>weren't<< like DECtape from a reliability standpoint ...
> ᐧ
>
> On Mon, Oct 15, 2018 at 5:00 PM Clem Cole  wrote:
>
>> Be careful, TK-50 is different than 9-track.  It's a streamer tape like
>> QIC, 4mm and 8mm.   The blocking is done under the covers by the HW and the
>> blovk size if just how a DMA is done.  I recommend that you pre-fetch the
>> read with dd or double-dd setting ibs=64k, obs=20b and conv=sync and pipe
>> the output to the reader (tar/cpio or the like) [if that fails try
>> obs=1b].   This should work well as can (TK-50 overall suck - don't set
>> your hopes high on anything with them -- they were DECtape from a
>> realiabilty standpoint, they were different from the reset of the world,
>> the performance was poor and they were expensive).
>>
>> Anyway, by using dd or the like a front end, it will allow the read
>> streamer to read as fast as it can.  The problem is that the way it works
>> under the cover does not shine with traditional UNIX I/O.  BTW: ibs of
>> anything more than 64K on a VAX (or PDP-11) will not help because of the
>> dma size on the Unibus caps DMA read/writes at 64K.   On a PMAX or (under
>> Tru64 on a Alpha), you can try using really large ibs sizes depending on
>> your physical memory size.
>>
>> BTW: What will help the most is actually finding a copy of the old
>> double-dd program (from the UUNET archives) which forks off two child
>> procees to perform the actual I/O and alternates between the two processes
>> via pipe between them and controller - so one dd process is reading when
>> the other dd process is writing.  [It used to be called: ddd before the
>> Gnu guys grabbed that name for the debugger].   The command line might be
>> something like:   ddd ibs=64k obs=20b | tar xvpf -
>>
>> FWIW:  I wrote a version of a fast dd years ago that used pthreads and a
>> semaphore that I should still have kicking around.   At one point when I
>> was dealing with streamer tapes for backup, I definitely ran it on Tru64
>> and FreeBSD, but  I've forgotten where Ultrix fell.
>> ᐧ
>>
>> On Mon, Oct 15, 2018 at 4:01 PM Warren Toomey  wrote:
>>
>>> All, I received this request from Matthew who isn't subscribed to either
>>> the TUHS or cctalk lists. He knows how to read the lists archives. Many
>>> thanks for any help you can provide.
>>> Cheers, Warren
>>>
>>> - Forwarded message from Matthew Whitehead -
>>>
>>> Date: Mon, 15 Oct 2018 08:25:39 -0400
>>> From: Matthew Whitehead
>>> Subject: Ultrix Tape Blocks
>>>
>>>Warren,
>>>  I wonder if you can give me a referral. I want to install Ultrix-32
>>>on my MicroVAX II using the ancient TK-50 tape drive. I know the tape
>>>files are on your archive, but I need to know the block size for each
>>>of the many files; it can vary a lot.
>>>Who might be able to help me with this?
>>>Matthew Whitehead
>>>
>>> - End forwarded message -
>>>
>>