Date: Mon, 8 Sep 1997 21:06:22 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: joerg_wunsch@uriah.heep.sax.de Cc: hackers@FreeBSD.ORG Subject: Re: Tape question Message-ID: <199709082106.OAA08434@usr09.primenet.com> In-Reply-To: <19970908073710.TX24990@uriah.heep.sax.de> from "J Wunsch" at Sep 8, 97 07:37:10 am
next in thread | previous in thread | raw e-mail | index | archive | help
> No, you were not unclear. You were wrong. We aren't talking about > `partial blocks' or such. We are talking about variable-length > recording tape drives, such as DAT, EXB-8mm, or QIC >= 525. In this > case, there's nothing like a `partial block', or a read or write > attempt crossing a `block boundary'. Any write(2) causes a media > block being written of the exact length that has been passed down to > this syscall. *UNLESS* the driver chooses to write out a block on a boundry that was decided upon by the driver, and pads the block regardless of the users requested transfer size. The driver can do this without the user's permission. Similarly, you may *request* a 8192 byte read, and the driver may not accept a shorter block being returned by the device in response to the larger request. This is what I believe is happening. Because the blocks were not written to the physical media with the requested read size, the read is failing. > Any > read(2) syscall is expected to specify a length that is at least the > size of the next tape block (otherwise an error will be signalled), > and will return the exact amount of bytes in the tape block. > > The person who's originally got the problem said the above expected > behaviour would work on a Sun but not on FreeBSD. My test case was to > prove it works on FreeBSD for me (that is, with a SymBios 83c810, and > a Tandberg TDC 4222 using QIC-525 cartridges). I can test it again > with an AHA-2940 and a DAT drive once i'm at work today. In point of fact, he said that when he issued a read for a tape block that requested more data than was in the physical tape block that was to be read, FreeBSD failed to operate as he expected. Whether or not it was legitimate for him to expect results other than those he got is debatable, and is a driver issue. You should know that the SCSI tape driver is the same for any SCSI controller, so the results of your proposed test are largely irrelevent, unless you believe the problem to be controller specific (admittedly, it may be that tape read requests returning short blocks are incorrectly handled in the Adaptec driver -- though I believe that this is unlikely; I think it's the st driver itself that is in error). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709082106.OAA08434>