Date: Mon, 14 Dec 1998 14:28:31 -0800 (PST) From: Matthew Jacob <mjacob@feral.com> To: Peter Jeremy <peter.jeremy@auss2.alcatel.com.au> Cc: freebsd-current@FreeBSD.ORG Subject: Re: Tape Driver Changes Proposed: Tape Early Warning Behaviour Message-ID: <Pine.LNX.4.04.9812141338310.2563-100000@feral-gw> In-Reply-To: <98Dec15.081550est.40374@border.alcanet.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> Matthew Jacob <mjacob@feral.com> wrote:
> > If EARLY WARNING recognitions is not enabled, then detection of EOM (as
> > reported in SCSI Sense Data with an EOM indicator) causes the write oper-
> > ation to be flagged with I/O error (EIO). This has the effect for the
> > user application of not knowing actually how many bytes were written
> > (since the return of the read(2) system call is set to -1).
> ^^^^^^^ presumably write(2)
D'oh! Yes...
> I also consider this behaviour to be a bug. Unfortunately, the Unix
> system call semantics don't provide any mechanism to report why a read
> or write terminated early.
That's why I want to use the 'short write' to be the signifcator.
>
> > the next attempt to write (if that is the next action the user application
> > takes)
> Does this mean that the EOM indication will be lost under some circumstances?
> Obviously is the tape is back-spaced, rewound or closed, the EOM should
> be cleared. Otherwise, I think the EOM should be kept.
If the user application does anything *but* a write following the latching
of state, that state should clear. I should note that even if logical EOM
does not continue to be reported (which as far as I can remeber it does
continue to be reported for all the drives I've tried this on) you still
have hard EOT to stop you from running off the end of the tape (*except*
for those few drives which don't do this- 1/2" Reels are the only ones
that come to mind).
>
> > is immediately completed with no data transferred, and a residual
> > returned to the user application indicating that no data was transferred.
> > This is the traditional UNIX EOF indication.
> It is for read(2). write(2) does not mention returning 0 to mean EOF. Do
> all applications obey this convention?
Apparently not. My recollections over a long period of time have made me
believe that this behaviour is symmetric, but other's do not atree.
>
> > In either mode of operation, the driver does not prohibit the user appli-
> > cation from writing more data, if chooses to do so.
>
> If I've understood this correctly, the behaviour will be as follows
> (ignoring tape blocksize and blocking factor issues), assuming we are
> 512 bytes before logical EOM and 2048 bytes before physical EOM:
>
> a) EARLY WARNING not enabled:
> write(fd, buf, 1024) returns -1, errno = EIO [512 bytes actually written]
> [tape now at logical EOM]
> write(fd, buf, 1024) returns 1024
> write(fd, buf, 1024) returns -1, errno = EIO [512 bytes actually written]
> [tape now at physical EOM]
>
> b) EARLY WARNING enabled:
> write(fd, buf, 1024) returns 512
> [tape now at logical EOM]
> write(fd, buf, 1024) returns 0 [indicating logical EOM]
> write(fd, buf, 1024) returns 1024
> write(fd, buf, 1024) returns -1, errno = EIO [512 bytes actually written]
> [tape now at physical EOM]
The actual behaviour is more likely to be (assuming the app doesn't stop)
a) EW not enabled (current behaviour)
i) write(fd, buf, 1024) returns -1, errno = EIO [1024 bytes written]
ii) write(fd, buf, 1024) returns -1, errno = EIO [1024 bytes written]
iii) write(fd, buf, 1024) returns -1, errno = EIO [0 bytes written]
This is because typically all the bytes transfer, but there is a CHECK
CONDITION associated with the operation which notes that EOM has been
reached (usually with the NO ADDITIONAL SENSE sense key). It isn't until
VOLUME OVERFLOW (3rd write) that bytes moved stops.
I should note that the pre-CAM driver actually stopped after #i, and that
if sastart in the top half of the current CAM driver paid attention to
the SA_FLAG_TAPE_MOUNTED flag it would also stop (but it doesn't). There's
a slight difference also if FIXED mode is set- if FIXED mode is set, an
EIO is deferred to the next I/O operation.
b) I am proposing that behaviour be
+ write(fd, buf, 1024) returns N, where N is the amount actually written
+ If, and only if N was 1024 (all bytes written) (and EOM had been
seen), the next write(fd, buf, 1024) returns 0 (0 bytes written).
So, assuming the usual tape drive behaviour, the scenario as above would
be:
i) write(fd, buf, 1024) returns 1024 (1024 bytes written) [ EOM flagged ]
ii) write(fd, buf, 1024) returns 0 (zero bytes moved) [ EOM cleared ]
iii) write(fd, buf, 1024) returns 1024 (1024 bytes written)
iv) write(fd, buf, 1024) will return -1 (ENOSPC or EIO - I don't care).
It really doesn't matter what the app does at #iv- you've hit hard eot and
can't do anything but rewind or space backwards.
It is expected that when #ii occurs the application could (in fact) write
a trailer record or two, but is expected to close the device or otherwise
cause a terminating filemark to be written and then rewind or do something
else.
Alternatively, if the drive reports EOM *and* reports that it didn't write
all that was requested, then step #ii is ommitted entirely (as the goal of
signification has been met). Further, let's say we have a broken or stupid
drive, and it doesn't even report EOM (just that it didn't write all that
was requested)- this acts (or should act) as a significator to the user
application (there's absolutely no reason for a tape device, or for that
matter (sez Bob Snively of the ANSI SCSI committee) for any device, to not
write all that was requested *unless* some limiting condition (like
physical impossibility) occurs).
>
> In both cases, I would prefer to see the following behaviour where the
> write returns -1 but actually writes something:
> write(fd, buf, 1024) returns 512
> [tape now at logical/physical EOM]
> write(fd, buf, 1024) returns -1, errno = EIO or ENOSPC
>
> The early warning behaviour is definitely preferable.
I still am bothered about reporting errors which aren't 'errors'. If I
write 1024 bytes to a tape and I get back two pieces of information- an
EIO and a notification that I wrote some data, which do you think I'll
believe?
> The issue of filemarks has not been addressed. Presumably, the system
> will try to write FM's, but may fail if the tape is beyond EOM. Will
> this be reported at all? Does it matter?
If you're before physical EOT you should be able to write filemarks (this
is why you need to signify to the application that physical EOT is
approaching).
> Presumably the behaviour of read(2) is unaffected by logical EOM: read(2)
> will return normally until EOF - indicated by a filemark or physical EOT.
End of recorded media (and/or filemark), yes.
>
> > However, the expected user application behaviour (in common
> > with other systems) is to close the tape and rewind and request another
> > tape upon the receipt of the first EOM indicator.
>
> If the application's logical blocksize is larger than the tape
> blocksize, the application will probably need to continue writing
> until it has completed a logical block. It may also need to write an
> application-dependent 'continued on next volume' block.
Yes.
>
> One final point: How do you enable/disable early warning? Is there
> any point in not always enabling early warning? Should the system
> default to early warning off and tape-aware applications can enable it
> (presumably via an ioctl)? Will it be user-selectable via a bit in
> the minor device number?
>
For NetBSD this was left as a config option (which I thought was stupid).
I'd like to make this behaviour the default.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.04.9812141338310.2563-100000>