11 Aug
2016
11 Aug
'16
2:08 p.m.
Joining the list of "my format" posts ...
Mine also records retry information (because MPE on the HP 3000
optionally reports if a retry was done to get a successful tape read),
and setmarks (which differ from EOFs), as well as error information.
(That retry information is important ... it could indicate a silent loss
of information.)
But, I must admit...it didn't occur to me to store metadata like
a photo of the tape, etc. Nice!
When copying / archiving tapes ...
One important thing to do, depending upon your operating system
and tape drive characteristics of course, is to issue read requests
for a few bytes more than you expect ... because with some OSs and
some kinds of drives, if you ask for X bytes and the record has more than X,
you'll quietly get X and the rest will be discarded. (That came up in a
court case where I was an expert witness ... an alleged 'expert' had
copied a 9-track tape (badly) and lost data because the records were larger
than
he expected, and his copying tool didn't have that simple safeguard in it.)
A second thing is to be somewhat aggressive in reading the 'end' of the
tape.
The backup tapes I frequently encounter supposedly end with two EOFs
in a row ... except for a few that happen to have extra data past that
point :)
(Of course, with 9 track tapes, you run the risk of going off the end!)
(Yes, that begs the question...if you're archiving a tar tape ... do you
*want*
the data past the first EOF? (Which could be part of a prior (and longer)
tar,
or something else.)) (And then there are the people who put tar after tar
after tar on the same tape :)
Stan
11 Aug
11 Aug
6:43 p.m.
On 08/11/2016 02:08 PM, Stan Sieler wrote:
One important thing to do, depending upon your
operating system and
tape drive characteristics of course, is to issue read requests for a
few bytes more than you expect ... because with some OSs and some
kinds of drives, if you ask for X bytes and the record has more than
X, you'll quietly get X and the rest will be discarded. (That came
up in a court case where I was an expert witness ... an alleged
'expert' had copied a 9-track tape (badly) and lost data because the
records were larger than he expected, and his copying tool didn't
have that simple safeguard in it.)
If you're using a SCSI drive, that's pretty simple to read the tape in
"variable" block mode, leaving a generous buffer--the result sense
status will tell how much was read.
Pertec drives are super-stupid, so you start reading and counting bytes
until the block ends.
A second thing is to be somewhat aggressive in reading
the 'end' of
the tape. The backup tapes I frequently encounter supposedly end with
two EOFs in a row ... except for a few that happen to have extra data
past that point :) (Of course, with 9 track tapes, you run the risk
of going off the end!)
I've had a couple of tapes with "fooler" double file marks. The first
was a zero-length file--had I thought to look at the block count
(000000) in the HDR label, it would have been obvious.
The second was a bit more involved--the tape started off in 6250 GCR
mode and read to EOF just fine. However, I picked up perhaps half a MB
of data, which seemed too little for a 10" reel. Rewind, manually set
the density to 1600 and read, letting the drive skip over what was now
interpreted as erased tape. What followed was a complete half-reel of
1600 data that would have been lost. My guess is that someone had an
"oh sh*t" moment, reset the density manually and finished the tape off
in the lower density as intended. I don't know if this could be
recovered with most SCSI streamers, which don't allow density changes
except at BOT.
War stories...I love 'em.
--Chuck
(Yes, that begs the question...if you're archiving a tar tape ... do
you *want* the data past the first EOF? (Which could be part of a
prior (and longer) tar, or something else.)) (And then there are the
people who put tar after tar after tar on the same tape :)
Stan
--
--Chuck
-------------------------------------------------------------
"The first thing we do, let's kill all the spammers."
10:50 p.m.
On 8/11/2016 6:43 PM, Chuck Guzis wrote:
On 08/11/2016 02:08 PM, Stan Sieler wrote:
<snip>
I've had a couple of tapes with "fooler" double file marks. The first
was a zero-length file--had I thought to look at the block count
(000000) in the HDR label, it would have been obvious.
The second was a bit more involved--the tape started off in 6250 GCR
mode and read to EOF just fine. However, I picked up perhaps half a MB
of data, which seemed too little for a 10" reel. Rewind, manually set
the density to 1600 and read, letting the drive skip over what was now
interpreted as erased tape. What followed was a complete half-reel of
1600 data that would have been lost. My guess is that someone had an
"oh sh*t" moment, reset the density manually and finished the tape off
in the lower density as intended.
That sounds like someone just set a Cipher 990 or
such to 6240 GCR and
overwrote it. The 1600bpi was residue which was previous tape contents?
Sometimes the stars align and there are not any tape errors when you do
what you do. Only way to know is whether there is a PE burst at the
start of the 1600bpi data, which would be there if they had done what
you suggest. And PE bursts should only appear @ the BOT I think as you
say with streamers.
I don't know what the rack Pertec PE formatters did. Those were the 4"
high boxes with a couple of boards with the original twin 50 pin input
IDC connectors on the back, and cabling out to the tape, which was a
Pertec of some sort.
I also had a 6" 600' only Pertec formatted, with a builtin PE
formatter. I don't know if either wrote the PE Burst.
That was mainly useful on the Cipher 1600 / 3200 drives to figure out
the density on read. (I think).
thanks
Jim
I don't know if this could be
recovered with most SCSI streamers, which don't allow density changes
except at BOT.
War stories...I love 'em.
--Chuck
(Yes, that begs the question...if you're
archiving a tar tape ... do
you *want* the data past the first EOF? (Which could be part of a
prior (and longer) tar, or something else.)) (And then there are the
people who put tar after tar after tar on the same tape :)
Stan
12 Aug
12 Aug
11:11 a.m.
On 08/11/2016 10:50 PM, jim stephens wrote:
That sounds like someone just set a Cipher 990 or such
to 6240 GCR
and overwrote it. The 1600bpi was residue which was previous tape
contents?
No, that's the odd thing--both files (tar) were complete from beginning
to end. The first was a smaller version of the second, but otherwise
complete. We'll never know how the thing got that way.
--Chuck
11:19 a.m.
On Aug 12, 2016, at 2:11 PM, Chuck Guzis <cclist at
sydex.com> wrote:
On 08/11/2016 10:50 PM, jim stephens wrote:
I think some drives can handle mid-tape density changes. It may even have been done by
DEC, though I may be confusing that with the odd case of RSTS distribution tapes which
started out with a DOS-11 label and then switched to ANSI labels.
paul
That sounds like someone just set a Cipher 990 or
such to 6240 GCR
and overwrote it. The 1600bpi was residue which was previous tape
contents?
No, that's the odd thing--both files (tar) were complete from beginning
to end. The first was a smaller version of the second, but otherwise
complete. We'll never know how the thing got that way.
12:06 p.m.
On 08/12/2016 11:19 AM, Paul Koning wrote:
I think some drives can handle mid-tape density
changes. It may even
have been done by DEC, though I may be confusing that with the odd
case of RSTS distribution tapes which started out with a DOS-11 label
and then switched to ANSI labels.
Sure, especially the older ones. (Doing it on the 60x/65x CDC drives was
mostly a matter of pushing a button). But what drive was used to write
this (DEC) tape is a mystery.
--Chuck
12:51 p.m.
On 8/12/16 12:06 PM, Chuck Guzis wrote:
But what drive was used to write
this (DEC) tape is a mystery.
DEC didn't sell a whole lot of different 1600/6250 drives.
TU78 was probably the most common.
and.. as I was writing this I remembered that it was possible to switch
densities on that drive mid-tape. I accidentally created a tar tape with
two different densities on it. I only tried reading it long after that
system was scrapped and found I couldn't.
3055
days inactive
3056
days old
7 comments
5 participants
participants (5)
-
aek＠bitsavers.org -
cclist＠sydex.com -
jwsmail＠jwsss.com -
paulkoning＠comcast.net -
sieler＠allegro.com