Date: Thu, 22 Apr 1999 09:54:56 -0700 (PWT) From: Matthew Jacob <mjacob@feral.com> To: Stephen McKay <syssgm@detir.qld.gov.au> Cc: Stefan Huerter <maulwurf@subloch.medicusnet.de>, freebsd-scsi@FreeBSD.ORG Subject: Re: i/o error with larger QIC Message-ID: <Pine.LNX.4.04.9904220944090.317-100000@feral.com> In-Reply-To: <199904221512.BAA10969@nymph.detir.qld.gov.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> > >> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.04.9904220944090.317-100000>