Date: Tue, 15 Dec 1998 08:16:29 +1100 From: Peter Jeremy <peter.jeremy@auss2.alcatel.com.au> To: freebsd-current@FreeBSD.ORG Cc: mjacob@feral.com Subject: Re: Tape Driver Changes Proposed: Tape Early Warning Behaviour Message-ID: <98Dec15.081550est.40374@border.alcanet.com.au>
next 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)
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.
> 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.
> 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?
> 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]
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.
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?
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.
> 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.
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?
Peter
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?98Dec15.081550est.40374>