Date: Sat, 25 Apr 1998 00:07:00 -0600 (MDT) From: "Justin T. Gibbs" <gibbs@narnia.plutotech.com> To: David Kelly <dkelly@HiWAAY.net> Cc: scsi@FreeBSD.ORG Subject: Re: does CAM do this? Message-ID: <199804250607.AAA03997@narnia.plutotech.com> In-Reply-To: <199804250221.VAA27227@nospam.hiwaay.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <199804250221.VAA27227@nospam.hiwaay.net> you wrote: > 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? There are two issues here. 1) MAX_BSIZE is 64k. This is the largest a buffer can be in the FreeBSD kernel unless you take advantage of some "modifications" John Dyson did that can allow larger buffers to be constructed. We really need to swith to a "buffer chaining" scheme (which appears to be the solution BSDI chose) to allow larger transactions. 2) Some adapters can only handle a few S/G segments at a time. The 1542 for example can only handle 16, which means the largest, page aligned, transfer possible, assuming all pages are discontiguous, is 64k. The aic7xxx cards have a limit of 255 S/G elements, but the driver currently allocates only 32 to save on space. After all, problem number 1 limits us to 64k anyway. To solve this problem, the bus dma implementation needs to be enhanced to perform smart page coalesing so that the transfer will fit in the S/G space supported by the target controller. I haven't come up with, or found an algorithm I like for doing this, so I haven't implemented it. These problems can be solved, but some discussion about the best approaches to solve them is required. > 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. I'm more than willing to review diffs. 8-) We have an O2 at work, so I can probably sniff how their mt blocksize works for the drives we have here, but I don't believe that a single strategy will work for all drives. I'll have to look at the spec again when I have some time. -- Justin 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?199804250607.AAA03997>