The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Warner Losh <imp@bsdimp.com>
To: Clem Cole <clemc@ccc.com>
Cc: The Eunuchs Hysterical Society <tuhs@tuhs.org>,
	"General Discussion: On-Topic and Off-Topic Posts"
	<cctalk@classiccmp.org>
Subject: Re: [TUHS] Ultrix Tape: Block Size?
Date: Mon, 15 Oct 2018 15:34:09 -0600	[thread overview]
Message-ID: <CANCZdfojLahTsUnfoe8sv-SBr1Fm=QwMpnj9wuqz9ip0S+Km=w@mail.gmail.com> (raw)
In-Reply-To: <CAC20D2MpVF2pv3k0vtZLSg26b82hQ=SHPDJy9RKH9vp_-vF7+w@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3309 bytes --]

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 <clemc@ccc.com> wrote:

> #$%^ - they >>weren't<< like DECtape from a reliability standpoint ...
> ᐧ
>
> On Mon, Oct 15, 2018 at 5:00 PM Clem Cole <clemc@ccc.com> 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 <wkt@tuhs.org> 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 -----
>>>
>>

[-- Attachment #2: Type: text/html, Size: 5221 bytes --]

  reply	other threads:[~2018-10-15 21:35 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-15 19:56 Warren Toomey
2018-10-15 21:00 ` Clem Cole
2018-10-15 21:01   ` Clem Cole
2018-10-15 21:34     ` Warner Losh [this message]
2018-10-16 16:57     ` Paul Winalski
2018-10-16 17:23       ` William Pechter
2018-10-16 17:34         ` Clem Cole
2018-10-16 17:34         ` Paul Winalski
     [not found]         ` <2658AACC-A451-4861-8CD8-F7E4BED8062A@comcast.net>
2018-10-17  6:14           ` [TUHS] TK50, was: " emanuel stiebler
2018-10-17 12:57             ` Tom Ivar Helbekkmo via TUHS
2018-10-18  7:48               ` Tom Ivar Helbekkmo via TUHS
2018-10-17 15:18             ` Clem Cole
2018-10-16 17:24       ` [TUHS] " Clem Cole
2018-10-19 21:17       ` Dave Horsfall
2018-10-15 21:52 ` Aaron Jackson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CANCZdfojLahTsUnfoe8sv-SBr1Fm=QwMpnj9wuqz9ip0S+Km=w@mail.gmail.com' \
    --to=imp@bsdimp.com \
    --cc=cctalk@classiccmp.org \
    --cc=clemc@ccc.com \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).