From owner-freebsd-scsi Thu Apr 22 9:58: 8 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 64BF714ECC for ; Thu, 22 Apr 1999 09:58:05 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from feral.com (mjacob@feral.com [192.67.166.1]) by feral.com (8.8.7/8.8.7) with ESMTP id JAA00479; Thu, 22 Apr 1999 09:54:57 -0700 Date: Thu, 22 Apr 1999 09:54:56 -0700 (PWT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Stephen McKay Cc: Stefan Huerter , freebsd-scsi@FreeBSD.ORG Subject: Re: i/o error with larger QIC In-Reply-To: <199904221512.BAA10969@nymph.detir.qld.gov.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > >> Do you remember what blocksize you *wrote* these tapes with? If you > >> do, set the blocksize for the drive fixed at that size and try > >> read with the tar command (setting to the blocksize you used to > >> write the tape). I really wish I had manuals for this drive so I > >> could try and figure what they're trying to do. > > > >I made a few tests before I get this tip from Joerg, so I tried to use tar > >with the blocksize of 10240bytes, but this won't work. I get only I/O > >errors... > > "10240bytes"? No, I mean 10240- but now that I've understood that variable emulation really *is* being done by newer QIC drives the attempts to set to fixed mode is pointless (personally, I think that this emulated variable mode is a grotesque design botch if (Reads in Variable mode of N-Kbytes) don't match (Reads in Fixed mode with blocksize at N-Kbytes), which is the impression I'm gathering from what people have said...). > > Do you mean 1024 bytes? If 'mt blocksize 0' doesn't work, then using > 'mt blocksize 1024' should work. The normal block size for these tapes > is 1024 bytes. It's really silly to use anything else for QIC525. But > the current tape driver doesn't know that... yet. Yes. I have a TANDBERG SLR-5 on order. I'm tired of screwing around with this. It arrives the middle of next week. Then I'll sit down and try and handle QIC drives more sensibly. What I may end up having to do is that it may be impossible to automatically correctly infer QIC behaviours without some hint from the user- and I don't want to get into a constant quirk game, so what would be people feel about a 'mt datamodel' type of command? Frankly, the big worry spot in a lot of this has been the toe stubbing around trying to do 2FM at EOT. Some drives support it, some drives don't. A lot of *early* QIC drives don't, but I'll have to admit that my QIC knowledge isn't what it should be- I really didn't keep up with QIC because most of the drives I've seen over the last 10 years have been DAT && Exabyte and other high end drives. Now that I'm getting a new high end QIC drive and I've already gotten an newer HP Travan-like drive (the T20) perhaps I might be able to produce something a little more sane for those of you out there that use these units. At any rate, if we could just accept a 1FM at EOT model with 2FM @EOT as the exception (solely for drives that cannot report early warning (1/2" reel drives) a *lot* of the problems would go away. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message