From owner-freebsd-scsi Fri Apr 23 1:49:44 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from ren.detir.qld.gov.au (ns.detir.qld.gov.au [203.46.81.66]) by hub.freebsd.org (Postfix) with ESMTP id 9957E14BCC for ; Fri, 23 Apr 1999 01:49:38 -0700 (PDT) (envelope-from syssgm@detir.qld.gov.au) Received: by ren.detir.qld.gov.au; id SAA01289; Fri, 23 Apr 1999 18:46:55 +1000 (EST) Received: from ogre.detir.qld.gov.au(167.123.8.3) by ren.detir.qld.gov.au via smap (4.1) id xma001271; Fri, 23 Apr 99 18:46:40 +1000 Received: from atlas.detir.qld.gov.au (atlas.detir.qld.gov.au [167.123.8.9]) by ogre.detir.qld.gov.au (8.8.8/8.8.7) with ESMTP id SAA16106 for ; Fri, 23 Apr 1999 18:46:40 +1000 (EST) Received: from nymph.detir.qld.gov.au (nymph.detir.qld.gov.au [167.123.10.10]) by atlas.detir.qld.gov.au (8.8.5/8.8.5) with ESMTP id SAA21773 for ; Fri, 23 Apr 1999 18:46:39 +1000 (EST) Received: from nymph.detir.qld.gov.au (localhost.detir.qld.gov.au [127.0.0.1]) by nymph.detir.qld.gov.au (8.8.8/8.8.7) with ESMTP id SAA01231; Fri, 23 Apr 1999 18:46:38 +1000 (EST) (envelope-from syssgm@nymph.detir.qld.gov.au) Message-Id: <199904230846.SAA01231@nymph.detir.qld.gov.au> To: freebsd-scsi@freebsd.org Cc: syssgm@detir.qld.gov.au Subject: Re: i/o error with larger QIC References: <19990422203034.22930@uriah.heep.sax.de> In-Reply-To: <19990422203034.22930@uriah.heep.sax.de> from J Wunsch at "Thu, 22 Apr 1999 20:30:34 +0200" Date: Fri, 23 Apr 1999 18:46:38 +1000 From: Stephen McKay Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thursday, 22nd April 1999, J Wunsch wrote: >As Stephen McKay wrote: > >> 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. > >Huh? Every QIC-525 tape i've seen so far seems to have used variable- >length recording. Sure, the underlying tape has to impose a blocksize >(of 1024 bytes), but that doesn't mean logical blocks could not be of >variable size. Interesting. I've used fixed 1024 byte blocks all the time to avoid the hassles of pretend variable length blocks. >Just to verify this, i dug up an old QIC-525 cartridge, and put it >into the TDC4222 drive under a fairly-current system. Running `tar t' >succeeded immediately since the driver had already been forced into >variable mode (which i'm currently doing from rc.local to work around >the driver problems). Looking at the tape's contents, it looks like >the cartridge has once been written on a Linux/AXP machine, so it >seems the interoperability in `variable' mode is fine. Hmm, hmm, i >notice the `tar: Blocksize = 1 records' on top, so this probably means >the tape has been written in 512-byte records? At least, i notice a >very poor performance. You are seeing a "feature" of the Tandberg, as far as I can tell. It will read fixed block tapes in variable mode, but very slowly. It is slow because every read() is satisfied by only 512 or 1024 bytes. If you were using fixed block mode, then each read() would return 10K or more (I use 32Kb for everything). Try using (say): dd if=/dev/rsa0 of=foo bs=32k count=10 and you will see 10 partial reads in variable mode, totalling 5K or 10K, and 10 full reads in fixed block mode, totalling 320K. [Interesting table removed] >Variable-length logical blocks seem to work best, ever. > >Fixed-legnth blocks (either 512 or 1024 bytes) have problems with read >speed. This seems to be a driver problem, in particular since the >read speed using variable-length read operations is better. Given >that the best possible values are at best en par with the variable- >length recording values, i don't see why anybody would use fixed- >length mode. But what block size did the application use when the tape was in fixed block mode? This is important, and affects the throughput. Eg, I use: $ mt blocksize 1024 $ tar cbf 64 /dev/nrsa0 foo bar bletch to use fixed block mode, but 32Kb transfers. I have no trouble keeping the tape streaming. So I don't see why anybody would use variable mode on these devices. :-) >The driver seems to have bugs, see ++ and ** above. Btw., `mt stat' >reports compression 0x3 everywhere, although i know that only QIC-2GB >and above support compression at all. Maybe this is part of the >problem? Yes, there are some bugs and misfeatures. I can test fixes, or if people are very patient, I can attempt to produce fixes. Stephen. PS Jörg, I know you don't like to be in the cc: list of responses, but since I turn my list mail into news, keeping me in the cc: list means I won't miss anything! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message