Date: Wed, 28 Apr 1999 09:12:30 -0700 (PWT) From: Matthew Jacob <mjacob@feral.com> To: amobbs@allstor-sw.co.uk 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.9904280909290.24720-100000@feral.com> In-Reply-To: <80256761.00572CBF.00@mail.plasmon.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > > >These are *amazingly* broken drives then. The SCSI specification says that > >a write of *zero* filemarks is to flush any pending writes. You have to do > >this when you do a read hardware position in order to avoid an ambiguity > >in the spec as to the true position as affected by data in the tape drive > >buffer. > > Doesn't Read Position (34h) give all the info you need, i.e. Physical pos., > logical pos. and number of blocks in buffer? I agree that flushing is > safer, but surely one could avoid it if necessary. > Now *that's* an area I would mistrust the f/w on- yes, you get number of blocks in the buffer (you use a flag in the cdb to select SCSI logical vs. hardware, and there's *nothing* that says that any device has to support either. STK drives puke on SCSI logical block reporting. DLT's puke on hardware block reporting). I think the patch I sent is probably the right approach. It's always a tradeoff- features vs. supporting really broken h/w. It really ticks me that this is broken. -matt 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.9904280909290.24720-100000>