Date: Sun, 25 Apr 1999 15:06:47 +0200 From: J Wunsch <j@uriah.heep.sax.de> To: freebsd-scsi@FreeBSD.ORG Cc: Stephen McKay <syssgm@detir.qld.gov.au> Subject: Re: i/o error with larger QIC Message-ID: <19990425150647.52666@uriah.heep.sax.de> In-Reply-To: <199904230846.SAA01231@nymph.detir.qld.gov.au>; from Stephen McKay on Fri, Apr 23, 1999 at 06:46:38PM %2B1000 References: <19990422203034.22930@uriah.heep.sax.de> <199904230846.SAA01231@nymph.detir.qld.gov.au>
next in thread | previous in thread | raw e-mail | index | archive | help
As Stephen McKay wrote: > >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. But well, why are we using `pretend' variable length blocks on the other tape drives then? Everything except half-inch pretends the variable-length recording (with more or less restrictions). Just to verify this assumption, i've fetched the Exabyte 8mm SCSI reference, and they're basically doing about the same as QIC >= 320. They use the same 1 KB physical blocks (with some more ECC data due to the nature of the helical-scan recording -- 400 bytes per each 1024 data bytes on 8 mm, as opposed to 2 physical 1024-byte blocks per each 14 physical data blocks on QIC). So, whenever you use those drives in variable-length mode (and i'm sure this applies to DDS and DLT as well), the drive actually splits the data to fit into physical blocks. The emulation may be better or worse, depending on the actual implementation, but who cares? The main differences i'm seeing between EXB 8mm and QIC >= 320 are: . The two more modern 8mm formats (8200c and 8500) can start logical blocks at arbitrary positions within a physical block, so they don't have to pad blocks. The old 8200 format is similar to the QIC way, logical blocks could span multiple physical blocks, but the remainder of the last physical block up to the next block boundary is padded. (There's one exception to this, i. e. two 512-byte logical blocks can share one 1024-byte physical QIC block. Thus, 512-byte fixed- length recording doesn't waste space on QIC.) . QIC only accepts three possible block size settings: 0 (variable), 512, 1024. 8 mm accepts everything up to 240 KB. I don't know how other tape systems behave here, but i haven't seen anybody who would use odd fixed-length blocksizes either, so it's probably rather a mood point. > 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 I'm not sure whether this is a feature of the Tandberg only, but i don't care right now. You're probably right, this returns short blocks. OTOH, my test series defeats your idea :), under some situations the data rate went up to the full QIC-525 speed again even for this combination. > 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: In my case, it was dump's default of 10 KB. From my experience, bumping it over 10 KB doesn't affect the overall throughput much, and beyond 32 KB, you'll hardly notice any improvement at all. So i figure this wasn't the key point in my measurements. > $ 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. :-) Because it's obsolete. :) Nobody uses it on the other tape drives either (even though all of them, of course, implement it). I have no problems with the speed in variable-length mode either, as long as the application is using a large enough block size. Speedwise, it makes no difference whether you pass the 32 KB in one transfer to the tape drive, and then have the tape considering it as a single logical block, or as 32 logical blocks (that are incidentally same length as the physical blocks then) of 1 KB each. OTOH, with variable-length mode, you can always get some data out of any tape, regardless how it has been written (provided your application uses a large enough blocksize at all to hold the blocks -- dump and GNUtar seem to work OK). Again, if fixed-length recording were that good, why don't the other tape drives use it? I think the only reason for using fixed-length recording on QIC (>= 320) is history... (Of course, with QIC-120/150, this differs a lot. The variable-length emulation there imposes so much restrictions that it's practically useless, and despite of it apparently being a QIC standard, i wouldn't be so sure whether all the QIC drives would really grok such tapes at all.) > 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! OK, it's only that my mailer can special-case replies to mailing lists, so _not_ keeping people in the Cc list is somewhat simpler for me. But i can honor your wish, no problem. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) 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?19990425150647.52666>