From owner-freebsd-scsi Sat Apr 25 21:31:57 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA12418 for freebsd-scsi-outgoing; Sat, 25 Apr 1998 21:31:57 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA12413 for ; Sat, 25 Apr 1998 21:31:54 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.8.8/8.7.3) id WAA12999; Sat, 25 Apr 1998 22:27:33 -0600 (MDT) Date: Sat, 25 Apr 1998 22:27:33 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199804260427.WAA12999@narnia.plutotech.com> To: Harlan Stenn cc: scsi@FreeBSD.ORG Subject: Re: does CAM do this? Newsgroups: pluto.freebsd.scsi In-Reply-To: <15923.893554380@brown.pfcs.com> User-Agent: tin/pre-1.4-971204 (UNIX) (FreeBSD/3.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article <15923.893554380@brown.pfcs.com> you wrote: >> > The problem is that a read() to the (default) tape drive under FreeBSD >> > returns exactly the number of bytes you asked for, so there is no way to >> > determine the actual number of bytes on the tape record. >> >> No, it returns no more than you asked for. That why you should do a >> read() of a record larger than you expect or can support, and it will >> return the number written in the tape record. > > I beg to differ. > > I agree that the read will return no more than I ask for. > > However... > > With the default tape drive configuration (on the drives I've tested), if I > have a Large file on the tape blocked at, say, 10k bytes, if I issue a > read of "more than 10k but less than the size of the file" I'll get back > exactly what I asked for. > > I cannot tell that the tape was blocked at 10k bytes. > > H This is probably because the old st driver does not set the B_ERROR buffer flag on a short read. If you don't set the B_ERROR flag while setting b_error to 0, physio will attempt to fill the user's buffer by attempting additional reads. The CAM driver behaves exactly as you wish. When a short read is encountered, the user is returned a short read. Just be aware, however, that if the device is in fixed block mode, your request must be a multiple of the block size. Should it be a multiple > 1, you will get more than a single block back. The only way to determine the block size in fixed block mode is to perform a smart search for the block size. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message