From owner-freebsd-scsi Wed Apr 28 12:22: 0 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (Postfix) with ESMTP id 9D21E14F92 for ; Wed, 28 Apr 1999 12:21:53 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id VAA05548 for freebsd-scsi@FreeBSD.ORG; Wed, 28 Apr 1999 21:21:52 +0200 (CEST) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.9.3/8.9.1) id VAA00807; Wed, 28 Apr 1999 21:08:36 +0200 (MET DST) (envelope-from j) Message-ID: <19990428210836.47084@uriah.heep.sax.de> Date: Wed, 28 Apr 1999 21:08:36 +0200 From: J Wunsch To: freebsd-scsi@FreeBSD.ORG Subject: Re: QIC tape problems on -stable (was: hanging `tar xfvR /dev/nrst0' process, can i debug it?) Reply-To: Joerg Wunsch References: <19990428091622.29861@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: ; from Matthew Jacob on Wed, Apr 28, 1999 at 08:39:34AM -0700 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Matthew Jacob wrote: > These are *amazingly* broken drives then. The SCSI specification > says that a write of *zero* filemarks is to flush any pending > writes. Well, but it doesn't say nothing must be written. ;-) The SCSI spec's a little thin in describing what needs to be done upon receipt of a WRITE FILEMARKS with a zero count, and what must not be done. However, i agree that's a bug in the Tandberg since it violates the Tandberg SCSI reference as well which indeed claims nothing would be written. However, trying to issue a WRITE FILEMARKS on a tape that has never been written so far is IMHO an mistake, and the SCSI specs don't seem to forbid that the drive refuses the command at all iff the medium is write-protected. So if at all, this `flush buffers' should IMHO only be done after the tape has actually been written to (which is already being tracked inside the driver). However(2), while i was at it, i traced the CAM CCBs, and i couldn't think of any scenario where a still-buffered write operation could get into your way at all. Whatever you're doing, either the application that holds the tape open for writing hasn't finished yet, in which case any further attempt to open the tape will be denied, or said application already caused a real filemark to be written (which by SCSI definition causes any buffered data to be written out before the WRITE FILEMARKS (with a count of >= 1) returns). So what's the scenario where you think you really need another WRITE FILEMARKS with a count of 0? > I believe that the writers of QIC f/w should be sent to > Redmond for the rest of their miserable lives. Nah, c'mon, it's just one bug in the firmware. By your terms, you could easily throw away almost any SCSI hardware since they often suffer more serious firmware bugs... -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message