Date: Wed, 22 Dec 1999 18:39:14 +1030 From: Greg Lehey <grog@lemis.com> To: Bruce Evans <bde@zeta.org.au> Cc: Matthew Jacob <mjacob@feral.com>, "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net>, freebsd-arch@freebsd.org, Stephen McKay <syssgm@detir.qld.gov.au>, Bob Bishop <rb@gid.co.uk>, Thomas David Rivers <rivers@dignus.com>, Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de>, Hauke Fath <hf@Melog.DE> Subject: Re: filemarks? Message-ID: <19991222183914.A1316@freebie.lemis.com>
next in thread | raw e-mail | index | archive | help
So much has been said about this subject that I can't work out which
statements to quote, so I'll start again.
What are we trying to achieve?
1. Get as much data as possible onto a tape.
2. Find a good transition point to subsequent tapes in a tape set.
3. Get it on a tape in such a way that we can reliably read it at a
later date, even on a different operating system.
4. Preferably, do it in a way which requires as little special
treatment as possible. This means, for example, that we should be
able to write one tape full with tools such as dd and cat.
What has been proposed?
Early warning:
If I understand this correctly, early warning can be supplied as a
hardware feature. I haven't quite understood what it is good for,
but two possibilities are that the software can then decide either
not to write the block, to write a short block, or to write one or
more tape marks.
If we use this feature at all, I think the driver should catch it,
not the application program. There are a number of possibilities:
1. Abort the write on early warning and write an EOF mark instead.
Return an EOF indication (write count 0). This sounds like the
most reliable way: it means we don't have to worry about partial
blocks. Any program writing tapes should be prepared to deal
with EOF.
2. Write a partial block and return the write count. As bde has
pointed out, there are problems in this area.
3. Write the complete block, assuming it's possible, then write an
EOF mark. Return success, but note that the tape is at EOF and
return EOF next time.
Of these three, I like (3) the best and (2) the least. The only
problem with (3) is knowing whether we can really write a complete
block after getting an early warning. Even if we can at the moment,
future devices or increases in the maximum block size may make it
impractical. Maybe the best alternative is:
4. Write the complete block, assuming it's possible, then write an
EOF mark. Return success, but note that the tape is at EOF and
return EOF next time (Case 3).
If it's not possible to write the complete block, backspace to
the beginning of the block (assuming we found out the hard way
that it wasn't possible), then write an EOF mark. Return an EOF
indication (write count 0) (Case 1).
If the drive doesn't support this function (backspace and write
EOT), write an EOT mark there and return the write count (case
2).
This sounds complicated, but I suspect that case 3 will almost
always apply.
Signals:
As I said above, I don't think that the user program should be
handling the EOF conditions. As a result, signals are superfluous.
Single EOF marks:
It's been a while since I handled ½" tapes, but my recollection was
that a single tape mark at the end of the reel meant "there are more
reels to come", and two tape marks meant "there are no more reels to
come". I'm prepared to be wrong on this, but if I'm not, we
obviously shouldn't be forgetting the second tape mark.
Reading:
I don't see that this is an issue. We attempt to read as much data
as requested. We return an indication of how much we actually read.
About the only issue I can think of is whether we should handle the
difference between one and two tape marks.
Comments?
Greg
--
Finger grog@lemis.com for PGP public key
See complete headers for address and phone numbers
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19991222183914.A1316>