On Fri, Oct 17, 2003 at 11:18:48AM +0200, JC Simonetti wrote:
> Just to be sure we are talking about the same thing [...]
We are indeed on the same wavelength.
> I have different values for the filemarks, measured with another program and
> not amtapetype.
> Do you know if the filemarks are application-dependant, tape-dependant,
> tape-and-taper-dependant ???
Doesn't surprise me.
A tape mark is a particular bit pattern on the tape (well, duh!).
Whether it's a funny otherwise-illegal block, which takes up some
amount of extra space, as I gather was the case with old
mainframe 9-track tape; or a one-bit field in a block header that
would have been written anyway, as seems a reasonable hypothesis
for "filemark 0" technologies like DDS; or something else,
depends on the drive technology.
So in theory, all tape marks written by a given drive should be
the same size.
But you can't read a tape mark. The whole idea is that it's a
way to represent an out-of-band signal, i.e. end of file. So the
drive reads the tape mark, but all it'll tell you about that is,
"I just read a tape mark". You don't get to see the magic bit
pattern.
Thus, programs *can't* find out a tape mark's size for sure; they
have to guess, using some heuristic or other. Different programs
will use different heuristics, so I suppose they'll guess
different values for what is in fact, the same quantity. We can
only hope that their guesses are "close enough" to the real
value.
Thus, the tape mark itself is not application-dependent, but the
estimate of its length *is*.
> The IBM fms software tells that filemarks are tape-and-taper-dependant. Do
> you know more? Do you have any opinions concerning that?
By "tape-and-taper-dependent", do you mean, "dependent on the
drive and on the particular tape"?
If so, I'd agree. In theory, as I said, it depends only on the
drive. But in practice, this is mag-tape we're talking about.
It's a notoriously unreliable medium. One way of dealing with
that, which was used by the old 9-track stuff, is that writing a
block consisted of:
1. Write the block
2. Go back and (try to) reread it
3. If you can't read it, skip forward a bit (erasing? Not sure)
and retry steps 1-2
4. All of this was happening within the hardware, i.e. within
one O/S-level I/O request. There was a threshold (number of
retries? length of tape consumed? Not sure) after which the
drive would give up and return an error status to the O/S
5. Perhaps the O/S would retry the failed write a few times
(steps 1-4, i.e. each software retry would involve many
hardware-level retries)
6. Perhaps the O/S would then print a message on the console
asking the operator what to do -- the mainframe equivalent of
"Abort, Retry, Fail?". If the operator said "retry", repeat
steps 1-6. Only if the operator said "fail" would the
application's I/O request (the local equivalent of the UNIX
write() sysstem call) finally return with an "I/O Error"
status.
Of course the read algorithms in both hardware and O/S knew to
compensate for all of that.
So you can see that there are potentially an *awful* lot of
retries going on there, each one consuming a small chunk of tape.
Thus, a tape record of a given length (whether a data block or a
tape mark) would always take up the same amount of tape *for the
record itself*, but the "inter-record gap" preceding the record
could vary wildly in length -- anywhere between a fraction of an
inch to several feet.
Thus, the *apparent* length of a tape mark (or of any other tape
record, for that matter) would depend not only on how much tape
the bit pattern itself occupied (constant, I presume), but on
whether you happened to try to write it on a bad patch of the
tape or a good one.
(I'm not sure how newer technologies deal with this
error-prone-ness; if they have better ways, the variablity in
apparent block lengths might be a lot less. But they haven't
been able to reduce that variability to zero -- at least not for
DDS3, judging by my amdump reports. And for streaming
technologies, that introduces yet another variable.)
So you can see that trying to intuit a tape mark's length is, to
put it mildly, a bit of a challenge.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont. erics AT telepres DOT com
| | /
When I came back around from the dark side, there in front of me would
be the landing area where the crew was, and the Earth, all in the view
of my window. I couldn't help but think that there in front of me was
all of humanity, except me.
- Michael Collins, Apollo 11 Command Module Pilot
|
