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 --]
next prev parent 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).