* [TUHS] Ultrix Tape: Block Size? @ 2018-10-15 19:56 Warren Toomey 2018-10-15 21:00 ` Clem Cole 2018-10-15 21:52 ` Aaron Jackson 0 siblings, 2 replies; 15+ messages in thread From: Warren Toomey @ 2018-10-15 19:56 UTC (permalink / raw) To: tuhs, cctalk 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 ----- ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [TUHS] Ultrix Tape: Block Size? 2018-10-15 19:56 [TUHS] Ultrix Tape: Block Size? Warren Toomey @ 2018-10-15 21:00 ` Clem Cole 2018-10-15 21:01 ` Clem Cole 2018-10-15 21:52 ` Aaron Jackson 1 sibling, 1 reply; 15+ messages in thread From: Clem Cole @ 2018-10-15 21:00 UTC (permalink / raw) To: Warren Toomey; +Cc: The Eunuchs Hysterical Society, cctalk [-- Attachment #1: Type: text/plain, Size: 2721 bytes --] 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: 4053 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [TUHS] Ultrix Tape: Block Size? 2018-10-15 21:00 ` Clem Cole @ 2018-10-15 21:01 ` Clem Cole 2018-10-15 21:34 ` Warner Losh 2018-10-16 16:57 ` Paul Winalski 0 siblings, 2 replies; 15+ messages in thread From: Clem Cole @ 2018-10-15 21:01 UTC (permalink / raw) To: Warren Toomey; +Cc: The Eunuchs Hysterical Society, cctalk [-- Attachment #1: Type: text/plain, Size: 2955 bytes --] #$%^ - 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: 4828 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [TUHS] Ultrix Tape: Block Size? 2018-10-15 21:01 ` Clem Cole @ 2018-10-15 21:34 ` Warner Losh 2018-10-16 16:57 ` Paul Winalski 1 sibling, 0 replies; 15+ messages in thread From: Warner Losh @ 2018-10-15 21:34 UTC (permalink / raw) To: Clem Cole Cc: The Eunuchs Hysterical Society, General Discussion: On-Topic and Off-Topic Posts [-- 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 --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [TUHS] Ultrix Tape: Block Size? 2018-10-15 21:01 ` Clem Cole 2018-10-15 21:34 ` Warner Losh @ 2018-10-16 16:57 ` Paul Winalski 2018-10-16 17:23 ` William Pechter ` (2 more replies) 1 sibling, 3 replies; 15+ messages in thread From: Paul Winalski @ 2018-10-16 16:57 UTC (permalink / raw) To: Clem Cole; +Cc: The Eunuchs Hysterical Society, cctalk On 10/15/18, Clem Cole <clemc@ccc.com> 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [TUHS] Ultrix Tape: Block Size? 2018-10-16 16:57 ` Paul Winalski @ 2018-10-16 17:23 ` William Pechter 2018-10-16 17:34 ` Clem Cole ` (2 more replies) 2018-10-16 17:24 ` [TUHS] " Clem Cole 2018-10-19 21:17 ` Dave Horsfall 2 siblings, 3 replies; 15+ messages in thread From: William Pechter @ 2018-10-16 17:23 UTC (permalink / raw) To: Clem Cole, Paul Winalski; +Cc: The Eunuchs Hysterical Society, 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 <paul.winalski@gmail.com> To: Clem Cole <clemc@ccc.com> Cc: The Eunuchs Hysterical Society <tuhs@tuhs.org>, cctalk@classiccmp.org Sent: Tue, 16 Oct 2018 13:14 Subject: Re: [TUHS] Ultrix Tape: Block Size? On 10/15/18, Clem Cole <clemc@ccc.com> 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [TUHS] Ultrix Tape: Block Size? 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> 2 siblings, 0 replies; 15+ messages in thread From: Clem Cole @ 2018-10-16 17:34 UTC (permalink / raw) To: William Pechter; +Cc: The Eunuchs Hysterical Society, cctalk [-- Attachment #1: Type: text/plain, Size: 2078 bytes --] 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 <pechter@gmail.com> 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 <paul.winalski@gmail.com> > To: Clem Cole <clemc@ccc.com> > Cc: The Eunuchs Hysterical Society <tuhs@tuhs.org>, cctalk@classiccmp.org > Sent: Tue, 16 Oct 2018 13:14 > Subject: Re: [TUHS] Ultrix Tape: Block Size? > > On 10/15/18, Clem Cole <clemc@ccc.com> 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. > [-- Attachment #2: Type: text/html, Size: 3769 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [TUHS] Ultrix Tape: Block Size? 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> 2 siblings, 0 replies; 15+ messages in thread From: Paul Winalski @ 2018-10-16 17:34 UTC (permalink / raw) To: William Pechter; +Cc: The Eunuchs Hysterical Society, cctalk On 10/16/18, William Pechter <pechter@gmail.com> 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <2658AACC-A451-4861-8CD8-F7E4BED8062A@comcast.net>]
* [TUHS] TK50, was: Re: Ultrix Tape: Block Size? [not found] ` <2658AACC-A451-4861-8CD8-F7E4BED8062A@comcast.net> @ 2018-10-17 6:14 ` emanuel stiebler 2018-10-17 12:57 ` Tom Ivar Helbekkmo via TUHS 2018-10-17 15:18 ` Clem Cole 0 siblings, 2 replies; 15+ messages in thread From: emanuel stiebler @ 2018-10-17 6:14 UTC (permalink / raw) To: Paul Koning, General Discussion: On-Topic and Off-Topic Posts, William Pechter Cc: The Eunuchs Hysterical Society On 2018-10-16 20:37, Paul Koning via cctalk wrote: > > >> On Oct 16, 2018, at 1:23 PM, William Pechter via cctalk <cctalk@classiccmp.org> 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 ... ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [TUHS] TK50, was: Re: Ultrix Tape: Block Size? 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 1 sibling, 1 reply; 15+ messages in thread From: Tom Ivar Helbekkmo via TUHS @ 2018-10-17 12:57 UTC (permalink / raw) To: emanuel stiebler Cc: Paul Koning, The Eunuchs Hysterical Society, General Discussion: On-Topic and Off-Topic Posts emanuel stiebler <emu@e-bbes.com> writes: > 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 ... Now *that* I wasn't aware of! Thanks! I'll have to open up my PDP-11/83 tonight. Its TK50 will stream while writing, as long as what's being written can be read reasonably fast from (RQDX3/RD54) disk. The TQK controller is sitting right up at the top end of the Q-bus, to get high priority -- but I don't know if it's a TQK70. I've really just assumed it's a TQK50 without thinking too much about it... -tih -- Most people who graduate with CS degrees don't understand the significance of Lisp. Lisp is the most important idea in computer science. --Alan Kay ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [TUHS] TK50, was: Re: Ultrix Tape: Block Size? 2018-10-17 12:57 ` Tom Ivar Helbekkmo via TUHS @ 2018-10-18 7:48 ` Tom Ivar Helbekkmo via TUHS 0 siblings, 0 replies; 15+ messages in thread From: Tom Ivar Helbekkmo via TUHS @ 2018-10-18 7:48 UTC (permalink / raw) To: Tom Ivar Helbekkmo via TUHS Cc: Paul Koning, General Discussion: On-Topic and Off-Topic Posts, The Eunuchs Hysterical Society I wrote: > I'll have to open up my PDP-11/83 tonight. Its TK50 will stream while > writing, as long as what's being written can be read reasonably fast > from (RQDX3/RD54) disk. The TQK controller is sitting right up at the > top end of the Q-bus, to get high priority -- but I don't know if it's a > TQK70. I've really just assumed it's a TQK50 without thinking too much > about it... Turns out it's an M7546; a TQK50. I guess I'll get streaming writes more often with an M7559 (TQK70) than I do at the moment, then. :) -tih -- Most people who graduate with CS degrees don't understand the significance of Lisp. Lisp is the most important idea in computer science. --Alan Kay ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [TUHS] TK50, was: Re: Ultrix Tape: Block Size? 2018-10-17 6:14 ` [TUHS] TK50, was: " emanuel stiebler 2018-10-17 12:57 ` Tom Ivar Helbekkmo via TUHS @ 2018-10-17 15:18 ` Clem Cole 1 sibling, 0 replies; 15+ messages in thread From: Clem Cole @ 2018-10-17 15:18 UTC (permalink / raw) To: emu; +Cc: Paul Koning, The Eunuchs Hysterical Society, cctalk [-- Attachment #1: Type: text/plain, Size: 8203 bytes --] 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 <emu@e-bbes.com> 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): <HW HDR BLK1 bit serial><512 bytes of serial data [blk1]><HW TLR BLK1 bit serial><HW HDR BLK2 bit serial><512 bytes of serial data[blk2]><HW TLR BLK2 bit serial>.....<HW HDR BLKn bit serial><512 bytes of serial data>[blkn]<HW TLR BLKn bit serial> The key is that there are no inter-record gaps (IRG) between the <HW TKR BLK x bit serial> and <<HW HDR BLK x+1 bit serial> 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): <HW HDR1><LRECL BYTES of BLK1><HW TRL2><IRG><HW HDR2><LRECL BYTES of BLK2><HW TRL2><IRG>......<HW HDRn><LRECL BYTES of BLKn><HW TRn> <IRG><HW EOT HDR>[if the last last 'file' on the tape a second<IRG><HW EOT HDR>] Note: LRECL BYTES of BLK1 did not have to be the same as <LRECL BYTES of BLK2> much less <LRECL BYTES of BLKn> 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 <IRG><HW EOT HDR> is backed up over and data frame writing starts over writing the second <HW EOT HDR> after the last <IRG> 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 you write on a streamer, it will always write it as 512 byte blocks (similar to how a disk works when set up in 'fixed' formatting). One more thing to be careful about... people also talk about 'ANSI tape' format. This usually refered to the *SW format of the data blocks on the tape*. UNIX's native tape formats were tp/stp, tar, cpio and dump. VMS uses the ANSI tape format as its native format under the covers (and if IIRC, so does RT11) for how to write and exchange data - which BTW, originally using those variable LRECL blocks on the tape. So the undustry first had a define a set if physical encoding for the tapes and these are also ANSI specs. But you need need to define how the data itself is written (which byte encoding ASCII vs EBCIDIC) and how to understand the 'files' on the tape itself (this is usually what is being tape about when people talk about 'ANSI tapes.' My old housemate at UCB (Tom Quarles, also known as the author of SPICE3) wrote the UNIX Ansitape program that went out with BSD (he wrote so we could exchnage tapes with the DEC CAD team which used VMS). Clem * Just to confuse you more, TK50 and the DLT family actually use a 1/2" media in the closed tape cartridge. But when DEC developed it (with 3M), there were also 3rd party 1/2" tape controllers that wrote bit serial (streamer) format on the traditonal 1/2" (9-track parallel) media. For instance the USAF/AWACS planes used to use a traditonal 3M 1/2" tape >>media<<, but those tapes can only be read on a special streamer drive [long story - I can make a couple of HW & SW guys shutter when I just say the word 'Grumman' ****]. ** One other thing to confuse the world is that 'streaming' was a trick performance trick that originated with 1/2" tape. You will see many 1/2" drives from the period such as ones from Cipher and Kenndy that took a parallel byte stream and wrote/read them - although they obey the 1/2" format rules on the tape itself. *** Another thing that was undefined in the ANSI tape specs and you can sometimes see, but certain HW will toss cookies and not read if you try it, it mix encoding within a tape (i.e. write 800 BPI, 1600 BPI or even 6250 BPI on the same tape). This was sometimes done on things like boot tapes because the pre-boot system might only know about 800 BPI tapes and it simplified the boot process particularly in the days when you had to toggle in the boot (or in IBM terms -- IPL -- initial program load -- code). **** An airman on the AWAC used to spent his entire time on the flight keeping the 3 drives loaded - it the time it took to write one tape, another is being rewound and the airman put a new tape on the 3rd - making that all work at full speed with no data loss was 'interesting' [-- Attachment #2: Type: text/html, Size: 14512 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [TUHS] Ultrix Tape: Block Size? 2018-10-16 16:57 ` Paul Winalski 2018-10-16 17:23 ` William Pechter @ 2018-10-16 17:24 ` Clem Cole 2018-10-19 21:17 ` Dave Horsfall 2 siblings, 0 replies; 15+ messages in thread From: Clem Cole @ 2018-10-16 17:24 UTC (permalink / raw) To: Paul Winalski; +Cc: The Eunuchs Hysterical Society, cctalk [-- Attachment #1: Type: text/plain, Size: 517 bytes --] On Tue, Oct 16, 2018 at 12:57 PM Paul Winalski <paul.winalski@gmail.com> 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). ᐧ [-- Attachment #2: Type: text/html, Size: 1732 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [TUHS] Ultrix Tape: Block Size? 2018-10-16 16:57 ` Paul Winalski 2018-10-16 17:23 ` William Pechter 2018-10-16 17:24 ` [TUHS] " Clem Cole @ 2018-10-19 21:17 ` Dave Horsfall 2 siblings, 0 replies; 15+ messages in thread From: Dave Horsfall @ 2018-10-19 21:17 UTC (permalink / raw) To: The Eunuchs Hysterical Society On Tue, 16 Oct 2018, Paul Winalski wrote: > The original DECtape was extremely reliable. [...] Indeed it was; a former boss used to tell the story of a salesman blowing cigarette smoke onto it (back when smoking was socially acceptable) and it just kept on working... -- Dave ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [TUHS] Ultrix Tape: Block Size? 2018-10-15 19:56 [TUHS] Ultrix Tape: Block Size? Warren Toomey 2018-10-15 21:00 ` Clem Cole @ 2018-10-15 21:52 ` Aaron Jackson 1 sibling, 0 replies; 15+ messages in thread From: Aaron Jackson @ 2018-10-15 21:52 UTC (permalink / raw) To: Warren Toomey, General Discussion: On-Topic and Off-Topic Posts; +Cc: tuhs If it is anything like installing NetBSD, which I have done on a VAXstation with a DLT4 drive, it should be 512 byte. So, while I do not know for sure for Ultrix and MicroVAX, 512 is probably a good starting point? Hopefully someone else will *actually* know. Aaron Warren Toomey via cctalk writes: > 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 ----- -- Aaron Jackson - M6PIU http://aaronsplace.co.uk/ ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2018-10-19 21:58 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-10-15 19:56 [TUHS] Ultrix Tape: Block Size? Warren Toomey 2018-10-15 21:00 ` Clem Cole 2018-10-15 21:01 ` Clem Cole 2018-10-15 21:34 ` Warner Losh 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
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).