Date: Wed, 22 Dec 1999 00:59:08 -0800 (PST) From: Matthew Jacob <mjacob@feral.com> To: Greg Lehey <grog@lemis.com> Cc: Bruce Evans <bde@zeta.org.au>, "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: <Pine.BSF.4.10.9912220021090.57747-100000@beppo.feral.com> In-Reply-To: <19991222183914.A1316@freebie.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Good summary, Greg, but let me respond...
On Wed, 22 Dec 1999, Greg Lehey wrote:
> So much has been said about this subject that I can't work out which
> statements to quote, so I'll start again.
>=20
> What are we trying to achieve?
>=20
> 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.
This is a pretty good summary, except I'd add:
5. Minimize the current h/w spasm each time somebody adds a new QIC or
TRAVAN-like drive which can't cope with double-filemarks which always
has to have them special cased.
>=20
> What has been proposed?
>=20
> Early warning:
>=20
> 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.
>=20
> If we use this feature at all, I think the driver should catch it,
> not the application program. There are a number of possibilities:
>=20
> 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.
>=20
> 2. Write a partial block and return the write count. As bde has
> pointed out, there are problems in this area.
>=20
> 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.
>=20
> 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:
>=20
> 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). =20
>=20
> 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).
>=20
> If the drive doesn't support this function (backspace and write
> EOT), write an EOT mark there and return the write count (case
> 2).
>=20
> This sounds complicated, but I suspect that case 3 will almost
> always apply.
I'm afraid that none of these are quite right.
First of all, EARLY WARNING is what you get when you're writing a tape and
a write completes with a CHECK CONDITION and the associated Sense Data
says that EOM has been detected (but the Sense Key is not VOLUME
OVERFLOW).
The residual count you get back with this is independent of the EOM
condition. Typically (read this is "Always, except I'm sure there's
*some* lameass tape drive out there that doesn't do this") the residual is
zero, i.e., the request completed successfully, but at the same time EARLY
WARNING is being signified. This truly should be taken to mean that "Yes,
the write succeeded, and, oh yes, btw, you might consider doing whatever
it is you'd like to do in preparation for switching volumes". This whole
furball of a discussion has been about trying to figure out how best to
pass the signification of EARLY WARNING back to the user application.
In my opinion, any residual count indicating that less than the amount
requested was written should be considered either an error or a
signification condition by the user application. If the return value to
the write system call is -1, that indicates an error. If the return value
is zero, it's a signification.
Now, in several of the scenarios above you have the driver write a
FILEMARK automatically. I don't believe that this is a good idea. The
application should drive what should be done here wrt filemarks- this is
driven by the application closing the tape device or issuing an ioctl to
write filemark(s).
If you believe that the driver should solely handle EOF conditions, then
the actual current behaviour is close to this.
The current behaviour is:
=09write has check condition:
=09=09If the error an EOM indication
=09=09=09if (fixed block mode)
=09=09=09=09mark EOM pending
=09=09=09else
=09=09=09=09mark current transfer failed with ENOSPC
(the difference between fixed block and variable block mode is a whole
discussion unto itself- suffice to say that the ENOSPC marking is done
at the top end in this case).
(there's a whole line of issues that have to do with failing a transfer
when it actually *succeeded*)
My proposed change was (some details left out):
=09write has check condition:
=09=09If the error an EOM indication
=09=09=09mark EOM pending, current transfer biodone as 'OK'.
=09Next write is returned indicating zero bytes moved (but no errno
=09set- yes there may be some issues in physio, but let's not go down
=09that path for now), POST_EARLY_WARNING flagged.
=09writes are allowed to continue at the discretion of the user
=09application, or the user application may decide to close the
=09device (whereupon {a filemark is}/{two filemarks are} written as
=09per spec and the selected EOT model for this device and either
=09the tape is rewound, or if the no rewind device, it just stays
=09there (except for the 2FM model, in which case the 2nd FM is
=09backed over- this is all normal stuff)).
=09If the application keeps writing, the application is deemed to
=09know what it wants to do. This may mean writing up until hard EOT
=09is hit and VOLUME OVERFLOW is seen (in which case -1/ENOSPC get
=09sent back).
With respect to your comment about using dd to write to the end of tape,
under this proposal, dd will write to the EARLY WARNING case and will errx
with an "end of device" diagnostic. Under the existing model, dd will
err with "no space on device" diagnostic, so this is no effective change.
> As I said above, I don't think that the user program should be
> handling the EOF conditions. As a result, signals are superfluous.
I don't see the application as handling EOF conditions- just being warned
that they are pending.
> Single EOF marks:
>=20
> It's been a while since I handled =BD" 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.
Sigh.... This is a whole large issue in and of itself.
>=20
> Reading:
>=20
> 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. =20
Well, I say one should keep reading until the drive reports hitting
unrecorded media (and a terrible misfeature of SCSI tape devices is their
almost universal inability to skip past erase-ahead gaps- so, if you write
a filemark on the front of a tape, you really can't get past the dead area
past the filemark to get at the N Gigabytes of valid data left. This does
not apply to 1/2" Reel tapes, but there sure aren't too many of those in
use that I can find ....).
-matt
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?Pine.BSF.4.10.9912220021090.57747-100000>