Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 24 Apr 1998 21:21:25 -0500
From:      David Kelly <dkelly@HiWAAY.net>
To:        freebsd-scsi@FreeBSD.ORG
Subject:   does CAM do this?
Message-ID:  <199804250221.VAA27227@nospam.hiwaay.net>

next in thread | raw e-mail | index | archive | help
I deal with a lot of tapes generated on SGI Irix systems, meaning 
"users who don't pay much attention to what they are doing." So 4mm 
tapes are usually blocked at 256k and 8mm's are 128k. I've never been 
able to detect a performance increase and if there is an advantage in 
getting more data on tape I've not noticed either. Then again I don't 
bump against the end of tape very often on purpose.

The FreeBSD 2.2.6 scsi system doesn't permit blocks larger than 64k. Or 
have I missed an enhancement? Today I noticed a new message:

st0: 262144-byte record too big

At least I think its new, but it accurately describes why I couldn't
read the tape. Does CAM provide for blocks larger than 64k? If not,
could CAM provide for blocks larger than 64k?

What are the hardware limitations? I don't think the Adaptec 7880 
family is inherently limited to 64k blocks else SGI did something 
special in the O2 to get around it. How about the Symbios '875?

Other things I'd really like to see is the ability to easily determine 
the tape block size of a tape. I know it can vary on tape, but the size 
of the first block under the head, or last block is good enough. SGI 
uses "mt blocksize" to read and set it. And while we're at it would an 
indication if the tape is compressed. I could probably add some of 
these things. I have Seagate's DAT manual and have been crawling thru 
tcopy experimenting with methods of querying the DAT drive for error 
and retry statistics.

We tcopy lots of tapes at work. Used 7,000 8mm tapes last year. Mostly 
with Solaris.

--
David Kelly N4HHE, dkelly@nospam.hiwaay.net
=====================================================================
The human mind ordinarily operates at only ten percent of its
capacity -- the rest is overhead for the operating system.



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?199804250221.VAA27227>