Date: Sat, 13 Jan 2001 14:43:24 -0800 (PST) From: Matthew Jacob <mjacob@feral.com> To: Eric Lee Green <eric@estinc.com> Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Why filemarks in sardpos? Message-ID: <Pine.LNX.4.21.0101131427140.32250-100000@zeppo.feral.com> In-Reply-To: <Pine.LNX.4.21.0101131422110.6204-100000@h23.estsatnet>
index | next in thread | previous in thread | raw e-mail
On Sat, 13 Jan 2001, Eric Lee Green wrote:
>
> if (softc->flags & SA_FLAG_TAPE_WRITTEN) {
> error = sawritefilemarks(periph, 0, 0);
> if (error && error != EACCES)
> return (error);
> }
>
The current implementation is somewhat simplistic, and yes, it's a performance
problem.
If you read the SCSI-2 spec, you'll notice that there are 2 entities of
interest with respect to this:
First Block Location
Last Block Location
The paragraphs of interest are:
---
The first block location field indicates the block address associated with the
current logical position. The value shall inidcate the block address of the
next data block to be transferred between the initiator and the target if a a
READ or WRITE command is issued.
The last block location field indicates the block address (see 10.1.6)
associated with the next block to be transferred from the buffer to the
medium. The value shall indicate the block address of the ntext data block to
be transferred between the buffer and the medium. If the buffer does not
contain a whole block of data or is empty, the value reported for the last
block location shall be equal to the value reported for the first block
location.
----
I elected to not trust tape firmware to get it right with respect to last
block location and played it safe by flushing any pending buffers to be
written when reading position. There is a lot of precedent for this- and
considering that any real formal testing is not done within *BSD, let alone
Linux, playing it safe with data integrity is a good idea.
I'd certainly be more open rethinking this, or making this a quirk. However,
your tone leads me to distrust statements of "we've tested", and since I'm the
moron responsible, all I can say is, "Dude! Have a nice day!".
-matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.21.0101131427140.32250-100000>