From owner-freebsd-scsi Sat Jan 13 14:43:44 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 69D4737B69D for ; Sat, 13 Jan 2001 14:43:26 -0800 (PST) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id OAA00682; Sat, 13 Jan 2001 14:43:25 -0800 Date: Sat, 13 Jan 2001 14:43:24 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Eric Lee Green Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Why filemarks in sardpos? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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