From owner-freebsd-scsi Wed Apr 28 23:41: 1 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 66B5C14CA2 for ; Wed, 28 Apr 1999 23:40:54 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from feral.com (mjacob@feral.com [192.67.166.1]) by feral.com (8.8.7/8.8.7) with ESMTP id XAA28388; Wed, 28 Apr 1999 23:40:34 -0700 Date: Wed, 28 Apr 1999 23:40:33 -0700 (PWT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Joerg Wunsch Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: QIC tape problems on -stable (was: hanging `tar xfvR /dev/nrst0' process, can i debug it?) In-Reply-To: <19990429082006.15161@uriah.heep.sax.de> 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 > As Matthew Jacob wrote: > > > > So what's the > > > scenario where you think you really need another WRITE FILEMARKS with > > > a count of 0? > > > > At < 10MB/s tape transport speed you'll have data in the tape buffers for > > geologic time after you've finished the WRITE command (remember- you're in > > buffered mode) and want to read position. > > Well, but you didn't read the remainder of my article, did you? I thought I had. I apologize if I hadn't. I was likely reading it over a very slow dsl line. > > The thing is, before you can get at issuing an ioctl(MTIOCRD*POS), > unless you're doing this inside the application that's currently > writing (none of the existing apps would do so), the application > writing data has to close the tape device first. Closing the tape > device after a write operation always results in writing at least one > filemark (withouth the `Imm' bit set in the CCB), so this by > definition flushes the write buffer. > Yes, but saying none of the current applications do the behaviour of write write rdhpos write is not correct behaviour. The expected and usual behaviour of this feature is to use it within an application- not via the mt(1) command. The expected usage would be likely be to read position and then write a record- and flushing a previous write is a good thing. It isn't just a case of flushing to make it easier for getting reported position. There have been proposed, I seem to recall, specific changes to the Solaris tape driver to handle DDI_SUSPEND events for the E10K class of machines- you get a DDI_SUSPEND, so you throw a 'Flush' at the drive so that the data that you've lied about being committed to media is actually committed to media. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message