Date: Sun, 13 Dec 1998 14:25:39 -0800 (PST) From: Matthew Jacob <mjacob@feral.com> To: Gary Jennejohn <garyj@muc.de> Cc: Greg Lehey <grog@lemis.com>, FreeBSD current users <FreeBSD-current@FreeBSD.ORG> Subject: (Re: Can't access tapes with scsi_sa.c r1.7) (LONG) Message-ID: <Pine.LNX.4.04.9812131312120.10954-100000@feral-gw> In-Reply-To: <199812131103.MAA00577@peedub.muc.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Well, I've been looking over this, and a preliminary check seems to indicate to me that the driver is, in fact, doing what it is supposed to do. Now, wait, don't start throwing things yet.. :-) The simple fix for all of you is to explicitly set variable mode (mt blocksize 0) on your tape device *if you want it to be in variable record length mode*, but see. If you're in fixed block mode (the default now that a lot of these drives show up as, but see below), and you issue a read that doesn't match the blocksize for that device, you get an ILI (incorrect length indicator) error- no data was actually transferred. I went back to the 1.6 version, added some debugging, and ran on a 8505 the same sorts of tests that Greg had done. The test here is you have a header record, say, of 512 bytes, followed by a filemark, and you read it with a 1k read from user space. Here's what had occurred: scsi_sa, 1.6: a) The device is in fixed block mode, but the tape driver is ignorant of this. This is because the old test at samount time was to see whether the maximum block size supported equaled the minimum blocksize, not what the actual current blocksize is. b) Thus, a read of 1k bytes gets shipped out as a variable mode read- not as a fixed length read. c) This gets returned, like a variable length read should, as having read 512 bytes of 1024 requested. This gets propagated back to the user application as a short read. All is good, if frightening because reality and driver state aren't coordinated, but.... !!!!!!!!The results of what occurs when you *write* such a device are not entirely predictable. Some tape devices, like the Exabyte 85XX and probably the Archive DAT drives, really don't care what 'mode' they're in but simply key off of each WRITE command as to what the actual record size being requested is. Other tape devices, e.g. the Exabyte 8200, get really bothered and just cannot cope. The main point of the 1.6 to 1.7 change was to address this. scsi_sa, 1.7: a) The device is in fixed block mode, and the tape driver is now cognizant of this because it keys off of what the actual current blocksize for the device is. b) A read of 1k bytes gets turned into a fixed length read of 1 record (1024 bytes) and shipped down to the drive- but the drive bounces the read because the only record available is the 512 byte record- and no data is actually then transferred and an error is returned to the user application. This is, in fact, the desired behaviour for fixed length record operations. Well, you *could* argue that SILI should be set (which supresses this error), but I would assert that you should just be operating in variable record mode when you want read variably sized records. If you use SILI, people will forget that they're in fixed block mode and when they write tapes with what *they* think are variable sized records, they won't be, which will be a zoo for media interchange.... In any case, the take home lesson of the change between scsi_sa 1.6 and 1.7 is that a 'fix' to actually make the driver operate as it is supposed to violated the principle of least surprise and nailed some folks- Sorry! scsi_sa, 1.8: (NOT YET INTEGRATED) What was *planned* was that in response to several requests, the *real* default behaviour should very likely be to to put all tape devices (with the exception of some QIC devices) into variable block mode at samount time unless someone has explicitly set fixed record mode. Opinions? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" 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.9812131312120.10954-100000>