From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: tuhs-bounces@minnie.tuhs.org X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,HTML_FONT_LOW_CONTRAST,HTML_MESSAGE, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id bf74fca8 for ; Mon, 15 Oct 2018 21:35:13 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 9764BA1E21; Tue, 16 Oct 2018 07:35:12 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 77CDA9E822; Tue, 16 Oct 2018 07:34:35 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id 869129E6F2; Tue, 16 Oct 2018 07:34:27 +1000 (AEST) Received: from mail-vs1-f50.google.com (mail-vs1-f50.google.com [209.85.217.50]) by minnie.tuhs.org (Postfix) with ESMTPS id D1D5F9E758 for ; Tue, 16 Oct 2018 07:34:21 +1000 (AEST) Received: by mail-vs1-f50.google.com with SMTP id r83so17184936vsc.4 for ; Mon, 15 Oct 2018 14:34:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SPuG/RuV5XM5TMfpIOKQKj6RgsMgk5ihIC+ZBpQjoCw=; b=L/3jN7id3hdPminQkh3frrwEiL5CDxAbPb6pdZH8TfarYgWEXio4OJ/ncpQQgHEaMC wV69N+b32NTUdDMbOMzRmSNOAxJvQaDp37yohYbAw0LvPnw4PMOwtfifMxlFBH5TYA+e RyTqatiUWesNNMHWfnSimSBkrLG8b6zAcAlPqWdwIkHYz8F+elrSgDQIhUiIiOaQMjj4 6a+TsbqnQwdZTRNU8gOoJB3pNwoBtvbW5F5UYeofBAe0MOUaEYQwyfkj5lAmt+4kcjhX VgQQOgJ1ofe+IPf6fCzWt53exYXT85auE+3AYvRLAb1TkyZ2p8dhoATfMcwNCxxFAx7f ViFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SPuG/RuV5XM5TMfpIOKQKj6RgsMgk5ihIC+ZBpQjoCw=; b=Gvq249i6QC14duFWNZX76shmsloXUsmtT/UW2cfoDR2WSVpM2LQ5MY/K05uMVQoz5P GgfImAhGfIPTeIEY+DtTTegvRFrkFrIm195cPJ5pPeelQwpOnkSmIbNXjtqKBGA3Ateb k0Bt/wu/glnFPRob0x9rMU1UAwfpJefdj0eJ5xQVulhCULZMwdSvwlZEdeO77V7f1CM5 /iTkhhXiMxkTkqPbHDqffsvCAxI0Z7dVmrhGaIWj9kjdn1LNylB9uuNZK1anEIZFEbh4 /tt8ZyHls06vBRA0U+aDJ3nI1BqofVQunvjdEhCsD5Pu9YHczz2xfbppFaZBT8LjqlYk oCLA== X-Gm-Message-State: ABuFfoiu1cPCe6DdHt8Z21rRlprF6clKazmMoqcE0XpvWIopjMzEGjcW qNuVjrdTZ+b5mLIvw6axaP6gaa3YeK+ybebGfGbhVw== X-Google-Smtp-Source: ACcGV60ufm0HRfQnX6Zej8+T+IOvuMAO0rFPd+CUa9XKs9wk5/xHjqqz3fNlXYayxdh7Xg3WNZKa9IXVaMzzXyPE1W0= X-Received: by 2002:a67:2704:: with SMTP id n4mr7730132vsn.209.1539639260667; Mon, 15 Oct 2018 14:34:20 -0700 (PDT) MIME-Version: 1.0 References: <20181015195622.GB25749@minnie.tuhs.org> In-Reply-To: From: Warner Losh Date: Mon, 15 Oct 2018 15:34:09 -0600 Message-ID: To: Clem Cole Content-Type: multipart/alternative; boundary="00000000000036f5da05784b3373" Subject: Re: [TUHS] Ultrix Tape: Block Size? X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: The Eunuchs Hysterical Society , "General Discussion: On-Topic and Off-Topic Posts" Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --00000000000036f5da05784b3373 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 ... > =E1=90=A7 > > 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 th= e >> read with dd or double-dd setting ibs=3D64k, obs=3D20b and conv=3Dsync a= nd pipe >> the output to the reader (tar/cpio or the like) [if that fails try >> obs=3D1b]. This should work well as can (TK-50 overall suck - don't se= t >> 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 work= s >> 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 (unde= r >> 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 process= es >> 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 b= e >> something like: ddd ibs=3D64k obs=3D20b | 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. >> =E1=90=A7 >> >> On Mon, Oct 15, 2018 at 4:01 PM Warren Toomey wrote: >> >>> All, I received this request from Matthew who isn't subscribed to eithe= r >>> 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-3= 2 >>> on my MicroVAX II using the ancient TK-50 tape drive. I know the tap= e >>> files are on your archive, but I need to know the block size for eac= h >>> of the many files; it can vary a lot. >>> Who might be able to help me with this? >>> Matthew Whitehead >>> >>> ----- End forwarded message ----- >>> >> --00000000000036f5da05784b3373 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 sail= or....

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 ...
3D""=E1=90=A7

On Mon, Oct 15, 2018 at 5:00 PM Clem Cole <clemc@ccc.com> wrote:<= br>
Be careful, TK-50 is different than 9-t= rack.=C2=A0 It's a streamer tape like QIC, 4mm=C2=A0and=C2=A08mm.=C2=A0= =C2=A0The blocking is done under the covers by the HW and the blovk size i= f just how a DMA is done.=C2=A0 I recommend that you pre-fetch the read wit= h dd or double-dd setting ibs=3D64k, obs=3D20b and conv=3Dsync and pipe the= output to the reader (tar/cpio=C2=A0or the like) [if that fails try obs=3D= 1b].=C2=A0 =C2=A0This should work well as can (TK-50 overall suck - don'= ;t set your hopes high on anything with them -- they were DECtape from a re= aliabilty=C2=A0standpoint, 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 wi= ll allow the read streamer to read as fast as it can.=C2=A0 The problem is = that the way it works under the cover does not shine with traditional UNIX = I/O.=C2=A0 BTW: ibs=C2=A0of anything more than 64K on a VAX (or PDP-11) wil= l not help because of the dma=C2=A0size on the Unibus=C2=A0caps DMA read/wr= ites at 64K.=C2=A0 =C2=A0On a PMAX or (under Tru64 on a Alpha), you can try= using really large ibs=C2=A0sizes depending on your physical memory size.<= /div>

<= font face=3D"arial, helvetica, sans-serif">BTW: What will help the most is = actually finding a copy of the old double-dd program (from the UUNET archiv= es) which forks off two child procees=C2=A0to perform the actual I/O and al= ternates between the two processes via pipe between them and controller - s= o one dd process is reading when the other dd process is writing.=C2=A0 [It= used to be called: ddd= =C2=A0before the Gnu guys grabbed that name for the debugger].=C2=A0 =C2=A0= The command line might be something like:=C2=A0 =C2=A0ddd=C2=A0ibs=3D64k obs=3D20b | tar xvpf -=C2=A0

FWIW:=C2=A0 I wrote a version o= f a fast dd years ago that used pthreads and a semaphore that I should stil= l have kicking around.=C2=A0 =C2=A0At one point when I was dealing with=C2= =A0streamer tapes for backup, I definitely ran it on Tru64 and FreeBSD, but= =C2=A0I've forgotten where Ultrix fell.
3D""=E1=90=A7

On Mon, Oct 15, 201= 8 at 4:01 PM Warren Toomey <wkt@tuhs.org> wrote:
A= ll, 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

=C2=A0 =C2=A0Warren,
=C2=A0 =C2=A0 =C2=A0I wonder if you can give me a referral. I want to insta= ll Ultrix-32
=C2=A0 =C2=A0on my MicroVAX II using the ancient TK-50 tape drive. I know t= he tape
=C2=A0 =C2=A0files are on your archive, but I need to know the block size f= or each
=C2=A0 =C2=A0of the many files; it can vary a lot.
=C2=A0 =C2=A0Who might be able to help me with this?
=C2=A0 =C2=A0Matthew Whitehead

----- End forwarded message -----
--00000000000036f5da05784b3373--