Date: Wed, 28 Apr 1999 23:40:33 -0700 (PWT) From: Matthew Jacob <mjacob@feral.com> To: Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de> Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: QIC tape problems on -stable (was: hanging `tar xfvR /dev/nrst0' process, can i debug it?) Message-ID: <Pine.LNX.4.04.9904282331480.28373-100000@feral.com> In-Reply-To: <19990429082006.15161@uriah.heep.sax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.04.9904282331480.28373-100000>